You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Aligned-in-packed restriction can be circumvented with generic parameters #80926
The effective layout seems to correspond to the layout used on non-MS platforms. This is quite useful to circumvent the restriction and I'll have to make use of it to interact with certain C apis as described in the RFC issue. So please don't remove it.
Do bear in mind that you are relying on what is explicitly been considered an unspecified behaviour. While this loophole existing does introduce some soft constraints for when the interaction between packed and align needs to be defined, it is not necessarily the case that Rust will be super hard-pressed to maintain the current behaviour.
I feel like we should just remove the aligned-in-packed check. There's probably already code out there relying on its current behavior via generics (even accidentally). And I don't think the behavior is particularly surprising either, packed acts on align types the same way it acts on all types -- it completely ignores their alignment.
Having types that can be written with generics but not monomorphic is obviously inconsistent, and means the check can at best serve as a lint anyway. We had a similar situation with repr(transparent) and that got fixed by also allowing the attribute on types where all fields are 1-ZST.
I wonder what @rust-lang/lang thinks about this -- the original goal was to avoid having to decide either way for the interaction of packed and align. Different C implementations seem to behave differently: on MSVC, __declspec(align(N)) types are fully aligned even in a packed struct; in GCC __attribute__((aligned(N))) types behave like all other types in a packed struct. But now that we inadvertently already made a decision to behave like GCC, is it really worth keeping the restriction?
We think the restriction can be safely lifted, in the manner described by @RalfJung above.
We would not object if the restriction were readded in the form of a best-effort lint. I.e., we do not see it as a downside if people are expected to explicitly add an #[allow] in the cases where they are putting an aligned type in a field of a packed struct, so that casual readers of the code will know something funky is going on.
Activity
jonas-schievink commentedon Jan 11, 2021
I think this works as intended? Packed representation ignores field alignment requirements
jonas-schievink commentedon Jan 11, 2021
Ah, apparently not:
Not sure what the rationale is there
nagisa commentedon Jan 12, 2021
rust-lang/rfcs#1358 (comment)
nagisa commentedon Jan 12, 2021
Do bear in mind that you are relying on what is explicitly been considered an unspecified behaviour. While this loophole existing does introduce some soft constraints for when the interaction between packed and align needs to be defined, it is not necessarily the case that Rust will be super hard-pressed to maintain the current behaviour.
mahkoh commentedon Jan 12, 2021
Nevertheless it is exactly the behavior documented in the reference if the sentence disallowing it were omitted.
RalfJung commentedon Aug 28, 2023
I feel like we should just remove the aligned-in-packed check. There's probably already code out there relying on its current behavior via generics (even accidentally). And I don't think the behavior is particularly surprising either,
packedacts onaligntypes the same way it acts on all types -- it completely ignores their alignment.Having types that can be written with generics but not monomorphic is obviously inconsistent, and means the check can at best serve as a lint anyway. We had a similar situation with
repr(transparent)and that got fixed by also allowing the attribute on types where all fields are 1-ZST.I wonder what @rust-lang/lang thinks about this -- the original goal was to avoid having to decide either way for the interaction of packed and align. Different C implementations seem to behave differently: on MSVC,
__declspec(align(N))types are fully aligned even in a packed struct; in GCC__attribute__((aligned(N)))types behave like all other types in a packed struct. But now that we inadvertently already made a decision to behave like GCC, is it really worth keeping the restriction?pnkfelix commentedon Sep 12, 2023
Discussed at T-lang triage meeting.
#[allow]in the cases where they are putting an aligned type in a field of a packed struct, so that casual readers of the code will know something funky is going on.@rustbot label: -I-lang-nominated
Rollup merge of rust-lang#162160 - RalfJung:aligned-in-packed, r=mu00…
Rollup merge of rust-lang#162160 - RalfJung:aligned-in-packed, r=mu00…
Unrolled build for #162160 in rollup 162767
Rollup merge of #162160 - RalfJung:aligned-in-packed, r=mu001999