Closed bocchino closed 4 months ago
So the buffer size in the generated code should be s + 1.
For strings defined in the framework, this is fixed in https://github.com/nasa/fprime/pull/2703. Still working on it for the auto-generated strings.
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:
const Fw::StringBase&
in the interface.Superseded by #423.
When a type
string size
s appears in FPP, the C++ code generator generates a classStringSize
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:
Fw::StringBase&
.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.char
array A of size s and (b) pass A into an instance of anExternalString
class that implements theStringBuffer
interface against A. See https://github.com/nasa/fprime/pull/2679. For string arrays, we can have an array of external strings backed by an array of arrays ofchar
.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 aString
object and serializing to bytes. It is always the max string length.This issue supersedes #387.