Description
Here, it says:
On the wire, length immediately precedes the data.
Which is 100% logical and correct. What bothers me is the next part Encoding specification. It says:
Variable length string is encoded as a composite type, consisting of a length sub field and data subfield
But it says nothing about the order of length and data fields, neither it does about the presence of other fields in that composite. I don't know if maintainers of this repo are connected to RealLogic and their implementation but they don't care about those things. They just take the length
member's type and use it to decode the length on the wire. And for that composite
type they generate the composite with fixed-length string of size 0
. It doesn't look good.
I see no reason to relate to composite type just to get the length type. This introduces unneeded complication and confusion. Why can't <data>
have its own set of attributes, one of which is lengthType
and everything else that makes sense for var-data fields only? Currently, <data>
has the same attributes as <field>
but it's not correct. offset
, presence
, valueRef
(and with my proposal type
) doesn't make any sense for var-data field. And <type>
s with length
should always be treated as a fixed-size arrays.