Repository navigation
#[repr(packed(N))] (tracking issue for RFC 1399) #33158
Description
Tracking issue for rust-lang/rfcs#1399: #[repr(packed(N))]
Unresolved issues
- Should borrows to packed fields be safe if the field's natural alignment is greater than or equal to the packing value, or should all fields of a packed struct always be unsafe to borrow?
- Currently
#[repr(packed(_))]structs cannot transitively contain#[repr(align(_))]structs due to differing behavior between msvc and gcc. Do we want to keep this a hard error, pick one behavior over the other, or provide some way to choose which behavior is desired?
Activity
retep998 commentedon May 26, 2016
#27060 is closely related to this.
bitshifter commentedon Apr 23, 2017
This should probably use
attr_literalsnow likerepr(align)does, e.g.repr(pack(2)).ahicks92 commentedon Jun 26, 2017
Is anyone working on this? If not I think I mostly know how to do it, modulo someone telling me how the attribute parsing and verification needs to be extended higher up.
ahicks92 commentedon Jun 27, 2017
Unless someone comes in and says they're doing this before then, I'm going to take a crack at it Friday or thereabouts. My intent is to use the attribute literals approach (or support both if that's what people want), plus potentially submitting a PR against the RFC repo to update the RFC to attribute literals.
@eddyb or whoever else might know: is inserting a bunch of
[0 x u8]in packed structs going to degrade performance? The easiest approach here seems to be to multiply everything in the type index to memory index vector by 2, then insert such dummy fields in packed structs. I think that everything else after that may just work except maybe constructing constants for them, but iirc constant construction is in one place and relatively easy for me to fix in this way.eddyb commentedon Jun 27, 2017
@camlorn everything currently has those usually-empty arrays, for
#[repr(align(N))].I also have a work-in-progress branch where I've simplified a lot of trans (including making constant ADTs boring), but there's more to be done - maybe I should try to polish it and open a PR soon.
ahicks92 commentedon Jun 28, 2017
@eddyb
Should I wait on you?
eddyb commentedon Jun 28, 2017
I'd say so, yes, at least for the trans part. In fact, I'm not sure there is anything left to do once I'm done, other than use the value from the attribute in the
alignfield.LegNeato commentedon Oct 19, 2017
@eddyb did you land the work-in-progress changes that were being discussed here?
eddyb commentedon Oct 19, 2017
@LegNeato They ended up in #45225, which might take a bit longer to get merged.
fitzgen commentedon Nov 1, 2017
Is there anything I can do to help implement and stabilize this feature? We need it badly for
bindgen.64 remaining items
rfcbot commentedon Dec 20, 2018
The final comment period, with a disposition to merge, as per the review above, is now complete.
Centril commentedon Dec 20, 2018
Any takers for a stabilization PR?
cramertj commentedon Dec 21, 2018
I'll do that.
Rollup merge of rust-lang#57049 - cramertj:repr-packed, r=Centril
Centril commentedon Dec 23, 2018
Reference documentation issue: rust-lang/reference#483.
ic3man5 commentedon Dec 12, 2023
Noting action item
seems to have been missed in review (unless I missed it reading through all the comments).
RalfJung commentedon Dec 12, 2023
That case still errors currently. So the resolution "keep this a hard error" was picked, maybe implicitly. This should be forward-compatible with the other options.
If you have further questions, I suggest asking on Zulip. Issue necromancy doesn't usually end well. ;)
ic3man5 commentedon Dec 12, 2023
@RalfJung Would opening a new issue be the correct solution then? If we want to have complete interoperability with C, this is a needed feature since C can align and pack at the same time. The linked issue does show a need for this feature.
RalfJung commentedon Dec 12, 2023
There are already issues for