I’m looking into zero-cost types for DSDL (Automatically detect zero-cost types · Issue #48 · OpenCyphal/pydsdl · GitHub)
One of the problems with this is you cannot have any variable length arrays. This will, invariably, lead to people who want to have zero-cost types defining fixed length arrays as buffers and then fill levels as integer fields. I’m wondering if we should formalize this by adding the concept of a variable fill static buffer type that is, simply, a fixed array with a fill length. The fixed array is then the maximum length of the data array and the fill is the transmitted length with the difference being padding. These types will always take up the same amount of memory both on the wire and in memory allowing for some variability within the maximum size of the static buffer but optimizing for zero-cost deserialization.
1 Like
I like this idea. Keeping the buffer size fixed while still having a usable length sounds like a reasonable compromise.
One small thing I’m wondering about is the padding. Would the unused part of the buffer need to have a defined value, or could it contain anything?
I’m not sure it matters for deserialization itself, but it seems like it could make a difference when comparing serialized data from different implementations.
Maybe that’s something worth clarifying in the specification.
1 Like
To encourage a secure protocol the standard should encourage the padding to be zeroed but that isn’t strictly required for this to be functional.
This appears reasonable.