fix: Allow sized C-like enums in Rust - #905
Conversation
The equivalent of enum class on C++
|
|
||
| /// Check for #[repr(C)] existence | ||
| /// Check whether the type is representable as C struct or enum. | ||
| fn has_repr_c(attrs: &[syn::Attribute]) -> bool { |
There was a problem hiding this comment.
| fn has_repr_c(attrs: &[syn::Attribute]) -> bool { | |
| fn has_repr_c_and_primitive(attrs: &[syn::Attribute]) -> bool { |
| if meta.input.peek(syn::token::Paren) { | ||
| let content; | ||
| syn::parenthesized!(content in meta.input); | ||
| let _ = content; | ||
| } | ||
| Ok(()) |
There was a problem hiding this comment.
I think padding should be handled by ABI, possibly through some kind of code generation tool. If we allow padding to be managed on the Rust side, but other applications or components do not apply the exact same rules, it could lead to compatibility issues.
I would recommend making #[repr(packed)] and #[repr(packed(N))] a compilation error when user put this.
There was a problem hiding this comment.
I have same opinion about align as well
There was a problem hiding this comment.
OK, I can also only allow repr(C) and repr(inttype) and forbid everything else if that is what we want. That effectively blocks a user from using align and packed on the data structure if using Rust while still being allowed on the C++ side. And this did work in the code before this PR so it would remove a "feature".
There was a problem hiding this comment.
My concern is that alignment and padding should be managed from a single source of truth for both C++ and Rust. If you look at the Rust examples, we write the corresponding C++ structure as well for FFI layer translation. If a user applies packing or custom alignment only on the Rust side and forgets to apply the same settings in C++, it can easily result in layout mismatches and misalignment issues.
So, if we want to support this feature, we need to ensure that both the Rust and C++ definitions are generated or configured with identical alignment requirements.
I'm not against adding the feature, but we need a mechanism to guarantee consistency across both sides. A Rust macro can validate attributes present on the Rust type, but currently we do not have a way to verify that the equivalent C++ structure has been defined with the same alignment characteristics. Without such validation, we risk introducing subtle interoperability bugs.
Partial fix for CodeQL/MISRA rule cpp/misra/signed-integer-overflow (RULE-4-1-3), finding at score/message_passing/client_connection.cpp:383 (alert eclipse-score#905, 'Operation / of type long may overflow or underflow'). Signed integer division only invokes undefined behavior when the divisor is -1 and the dividend equals the type's minimum value. kConnectRetryT is a namespace-scope constexpr positive constant (3), so it can never be 0 or -1 and this division can never overflow. Add a static_assert establishing that invariant at the point of use so the guarantee is visible and enforced at compile time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2 participants
The equivalent of enum class: size_type on C++