fixed size arrays can be initialised with more values than capacity

[christianrauch]

When using the fixed-sized arrays, e.g. int_array_fixed_XX, it is possible to provide more values than capacity (XX).

The parameter configuration:

  bla:
    type: int_array_fixed_03
    read_only: true
    default_value: [101, 102, 103, 104]

generates:

rsl::StaticVector<int64_t, 3> bla = {{101, 102, 103, 104}};

resulting in the collection.size() <= capacity assert triggered here:

Source "/opt/ros/jazzy/include/rsl/rsl/static_vector.hpp", line 33, in StaticVector<std::vector<long int, std::allocator<long int> > > [0x717072a9337d]
   30:      */
   31:     template <typename Collection>
   32:     StaticVector(Collection const& collection) : size_(std::min(collection.size(), capacity)) {
>  33:         assert(collection.size() <= capacity &&
   34:                "rsl::StaticVector::StaticVector: Input exceeds capacity");

Not even a fixed_size<>: 3:

  bla:
    type: int_array_fixed_03
    read_only: true
    default_value: [101, 102, 103, 104]
    validation:
      fixed_size<>: 3

will prevent this as the rsl::StaticVector<> is constructed before the checks.

Also, it is possible to provide fewer than XX values. As the name suggests, I would expect that the size of the array is fixed, and that it holds exactly XX elements, not more and not less.

Is there a reason why rsl::StaticVector<int64_t, 3> is used in place of std::array<int64_t, 3>? The latter is much more widely used and has all the standard compiler checks. E.g. something like std::array<int64_t, 3> bla = {{101, 102, 103, 104}}; would not compile and not create "runtime surprises".

Would you consider replacing rsl::StaticVector<T, N> with std::array<T, N> to avoid these issues?

[christophfroehlich]

I suppose that the problem is that validators are only evaluated at runtime, but not during code generation for default values. However, this should be possible to implement.

Is there a reason why rsl::StaticVector<int64_t, 3> is used in place of std::array<int64_t, 3>? The latter is much more widely used and has all the standard compiler checks. E.g. something like std::array<int64_t, 3> bla = {{101, 102, 103, 104}}; would not compile and not create "runtime surprises".

As I see from the failing builds in your draft PR: there is no assignment overload from rclcpp parameter to std::vector->std::array.
These compiler checks could be added to RSL, too?

[christianrauch]

rsl::StaticVector has this Collection-templated constructor that allows it to take a std::vector<> directly, and which makes the code generation easier. And yeah, this is not possible for std::array<>. Therefore, this conversion would involve more code generation. I guess I would only look into this more deeply when there is consensus to replace rsl::StaticVector with std types.