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
Meeting proposal: When accessing a field that is at a "very aligned" offset, can the required alignment be higher than the type of the field indicates? #11
Sometimes when accessing a field, the alignment requirement is lower than the type of the field might indicate: specifically, this happens for fields of repr(packed) structs.
Can the alignment requirement ever be higher? For instance, in this type
#[repr(C)]structS{x:u8,y:u32}
the x field will always be at a 4-aligned address when occurring inside a well-aligned S instance. Therefore, Miri will make (*ptr).x UB if that load is not 4-aligned. This matches codegen which generates an align 4 load in this example.
Is that what we want, or should the alignment requirements of a field access in a struct always be upper-bounded by the alignment of that field?
These issues are meant to be used as an "announcements channel" regarding the proposal, and not as a
place to discuss the technical details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision. In the meantime, if you have
questions or ideas, ping the proposers on Zulip (or elsewhere).
changed the title [-]When accessing a field that is at a "very aligned" offset, can the required alignment be higher than the type of the field indicates?[/-][+]Meeting proposal: When accessing a field that is at a "very aligned" offset, can the required alignment be higher than the type of the field indicates?[/+]on Aug 19, 2023
I will write up an FCP proposing to limit alignment requirements to field type. There wasn't a clear consensus though so we might have to keep discussing asynchronously.
The main issue is that we don't know what kind of code out there would be affected by this, and how tricky it would be to get back the lost alignment assumption in case someone needs it. In monomorphic code a read_aligned<const ALIGN: usize> operation goes a long way, but in generic code that could be tricky.
Actually while trying to write up the current rules for rust-lang/reference#1387 I realized there is a way to state them that isn't even that complicated. So I am no longer convinced we want to allow these examples. I do think we want to treat all 3 examples consistently, but there's a way to disallow them that's not so bad...
As the one who proposed this meeting, and given the voices during the meeting that said they were worried about allowing this code (which has no clear motivation to be allowed besides "the rules are confusing"), only to realize later that we'd really like the optimization potential enabled by the UB -- I no longer think I want to change anything here, for now. If rust-lang/reference#1387 lands as-is, I think am happy with our alignment rules. (I'll know for sure after implementing this in Miri, but the MiniRust implementation makes me optimistic.)
So, I don't think I will be going for any FCP here. (An FCP for "change nothing" just seemed odd.)
Meeting proposal: When accessing a field that is at a "very aligned" offset, can the required alignment be higher than the type of the field indicates? · Issue #11 · rust-lang/opsem-team
Activity
[-]When accessing a field that is at a "very aligned" offset, can the required alignment be higher than the type of the field indicates?[/-][+]Meeting proposal: When accessing a field that is at a "very aligned" offset, can the required alignment be higher than the type of the field indicates?[/+]RalfJung commentedon Aug 22, 2023
I will write up an FCP proposing to limit alignment requirements to field type. There wasn't a clear consensus though so we might have to keep discussing asynchronously.
The main issue is that we don't know what kind of code out there would be affected by this, and how tricky it would be to get back the lost alignment assumption in case someone needs it. In monomorphic code a
read_aligned<const ALIGN: usize>
operation goes a long way, but in generic code that could be tricky.RalfJung commentedon Aug 23, 2023
Actually while trying to write up the current rules for rust-lang/reference#1387 I realized there is a way to state them that isn't even that complicated. So I am no longer convinced we want to allow these examples. I do think we want to treat all 3 examples consistently, but there's a way to disallow them that's not so bad...
RalfJung commentedon Aug 25, 2023
As the one who proposed this meeting, and given the voices during the meeting that said they were worried about allowing this code (which has no clear motivation to be allowed besides "the rules are confusing"), only to realize later that we'd really like the optimization potential enabled by the UB -- I no longer think I want to change anything here, for now. If rust-lang/reference#1387 lands as-is, I think am happy with our alignment rules. (I'll know for sure after implementing this in Miri, but the MiniRust implementation makes me optimistic.)
So, I don't think I will be going for any FCP here. (An FCP for "change nothing" just seemed odd.)