Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimize use of auto-generated string types in C++ code gen #406

Closed
3 tasks
bocchino opened this issue Apr 12, 2024 · 3 comments
Closed
3 tasks

Minimize use of auto-generated string types in C++ code gen #406

bocchino opened this issue Apr 12, 2024 · 3 comments
Assignees
Labels
code generation Issues related to code generation f prime integration Issues related to integration with F Prime
Milestone

Comments

@bocchino
Copy link
Collaborator

bocchino commented Apr 12, 2024

When a type string size s appears in FPP, the C++ code generator generates a class StringSize s. These generated string classes appear in array, struct, and port definitions.

This code generation is inefficient and awkward. Instead of generating all these string classes, we should do the following:

  1. When passing or returning a string value by reference, don't use a concrete string type; instead use Fw::StringBase&.
  2. When Fw::StringBase& is passed to a string parameter that has size s, bound the size to s when computing the serialized size or when serializing the bytes.
  3. When allocating a concrete string of size s, (a) declare a char array A of size s and (b) pass A into an instance of an ExternalString class that implements the StringBuffer interface against A. See Add Fw::ExternalString and revise string implementations fprime#2679. For string arrays, we can have an array of external strings backed by an array of arrays of char.
  4. When computing the static serialized size of an external string (e.g., in sizing a message on the queue), have the code generator fill in the size directly, instead of using the SERIALIZED_SIZE constant. This constant will not exist for external strings, since there is no known static serialized size for this type.

I also note that the current string class generation has a subtle bug, or idiosyncrasy: string size s generates a string type with a buffer of size s. However, F Prime strings are null-terminated when they are stored in buffers (but not when they are serialized), so strings stored into a buffer of size s are truncated to max length s - 1. I think the FPP string size should represent the maximum string length, not the max string length minus one. So the buffer size in the generated code should be s + 1. This way the meaning of the string size is consistent across both cases: storing in a String object and serializing to bytes. It is always the max string length.

This issue supersedes #387.

  • Arrays
  • Structs
  • Ports
@bocchino bocchino added the code generation Issues related to code generation label Apr 12, 2024
@bocchino bocchino added this to the v2.1.0 milestone Apr 12, 2024
@bocchino bocchino self-assigned this Apr 12, 2024
@bocchino bocchino added this to To do in Fixes and Enhancements via automation Apr 12, 2024
@bocchino bocchino moved this from To do to In progress in Fixes and Enhancements Apr 18, 2024
@bocchino bocchino moved this from In progress to To do in Fixes and Enhancements Apr 18, 2024
@bocchino bocchino added the f prime integration Issues related to integration with F Prime label Apr 25, 2024
@bocchino
Copy link
Collaborator Author

bocchino commented Apr 30, 2024

So the buffer size in the generated code should be s + 1.

For strings defined in the framework, this is fixed in nasa/fprime#2703. Still working on it for the auto-generated strings.

@bocchino
Copy link
Collaborator Author

bocchino commented Apr 30, 2024

I'm rethinking this issue a bit. Completely eliminating auto-generated string classes is challenging, because we need to construct arrays of strings, and because we sometimes need the string representation in the interface. I think we should do the following:

  1. Simplify the auto-generated strings as we have done in the framework code.
  2. Switch as much as possible to using const Fw::StringBase& in the interface.
  3. Where we have to use a generated string type in the interface, make sure that a type alias is available so that user code does not depend on the string size.
  4. Minimize reliance on implicit constructor calls.
  5. Fix the off-by-one error in the buffer sizes for generated strings.

@bocchino bocchino changed the title Eliminate per-use string classes from C++ code gen Minimize use of auto-generated string types in C++ code gen Apr 30, 2024
@bocchino
Copy link
Collaborator Author

Superseded by #423.

@bocchino bocchino closed this as not planned Won't fix, can't repro, duplicate, stale Apr 30, 2024
Fixes and Enhancements automation moved this from To do to Done Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code generation Issues related to code generation f prime integration Issues related to integration with F Prime
Projects
Development

No branches or pull requests

1 participant