Consider Removing use of Variable Length Arrays for Async Serializable Ports

[Joshua-Anderson]

Because serialized ports don't have a predefined message size, users declare the maximum message size at component initialization.

When a user enqueues a message in an async port, the autocoder has to prepend the port ID and port number to the message so that the port can be properly handled when dequeued.

The way this is currently implemented is:

• Create a message buffer from a variable length array of maximum message size (provided at initialization)
• Add port id and number to message buffer.
• Copy user provided data into message buffer
• enqueue message buffer.

While this is a perfect use case for variable length arrays, use of variable length arrays is discouraged because they're not part of the C++ standard (they're a gcc extension).

Unfortunately, there's no good alternative... this message buffer can't be dynamically heap allocated. We could make the maximum serialized port message size some sort of constant (part of the component model?) rather than a runtime option, but that would likely require users modify the builtin F' components whenever they'd need to adjust this constant, breaking the reusability of F' components.

[matt392code]

fprime-std-array.txt
Several potential solutions to address the variable-length array concern in F' serializable ports are below:
Key Challenges:

1. Need to handle variable message sizes
2. Must avoid heap allocation during message processing
3. Need to maintain component reusability
4. Must be C++ standard compliant
5. Performance critical for spacecraft control

Proposed Solutions:

1. std::array with compile-time maximum size

• Pros:
  • Standard C++ compliant
  • Zero heap allocation
  • Predictable memory usage
• Cons:
  • Requires template parameter
  • May waste memory if maximum size is much larger than typical messages

2. Compile-time configuration with inheritance

• Pros:
  • Allows customization per component
  • Standard compliant
  • No runtime overhead
• Cons:
  • Less flexible than runtime configuration
  • Requires recompilation to change sizes

3. std::vector with reserve()

• Pros:
  • More flexible
  • Standard compliant
  • Memory efficient
• Cons:
  • Still uses heap allocation (though only once at initialization)
  • Slightly higher memory overhead

4. Flexible array member

• Pros:
  • Single allocation at initialization
  • Memory efficient
  • Standard C++ feature
• Cons:
  • More complex implementation
  • Requires careful memory management

Recommendation:
For spacecraft control software, I would recommend Solution 1 (std::array) or Solution 2 (compile-time configuration) because they:

1. Have zero heap allocation
2. Are completely predictable at compile time
3. Have minimal runtime overhead
4. Are easiest to verify for correctness

The trade-off of compile-time configuration vs runtime flexibility seems acceptable given the critical nature of spacecraft control software, where predictability and reliability are paramount.