-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guarantee repr(C) enum discriminants are stable within a compilation #1454
base: master
Are you sure you want to change the base?
Conversation
…within a compilation
Friendly ping 🙂 |
1 similar comment
Friendly ping 🙂 |
Is there some context for this change? Has it been discussed by the lang team? |
> discriminants will have the same size and alignment *within a given | ||
> compilation of the program.* This is true for both field-less enums and | ||
> for enums with fields. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"within a given compilation of the program" doesn't seem clear to me what that means. Certainly all types have the same size and alignment during compilation. I'm not sure I can guess what this is trying to say, can you clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should phrase this differently. The idea is that, whatever choice rustc makes about the size and alignment of the discriminant of a repr(C)
enum, it makes the same choice for all repr(C)
enums within a program.
The reason this is important is that the size and alignment aren't guaranteed in any way other than to say "rustc will choose some size and alignment." This puts unsafe code in a bind: how do you know what the size and alignment of the discriminant is if you're trying to work with the layout of an enum type? With this added text, you can construct a "dummy" field-less repr(C)
enum, query for its size and alignment using size_of
and align_of
, and take these to be equal to the size and alignment of the discriminant of the enum you're working with.
The specific context is that zerocopy's TryFromBytes
trait can currently be derived on field-less enums, and we want to add support for data-ful enums, but we can't without this guarantee (or some other way of querying for the size and alignment of repr(C)
enum discriminants).
No, but I figured it'd be pretty uncontroversial. Happy to CC them here if you'd like. |
No description provided.