-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Document soundness of Integer -> Pointer -> Integer conversions in const
contexts.
#113510
Document soundness of Integer -> Pointer -> Integer conversions in const
contexts.
#113510
Conversation
e4b522d
to
1c20573
Compare
LGTM. However, I think we need the lang team to bless this. Nominating for their discussion. |
@RalfJung Are there any const operations that can be done on the pointer (between the transmutes) that would make this unsound? |
No, in const you can never turn an integer value into a pointer value. |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
Absolutely in favour in the abstract 👍 I do think, though, that we want it to be able to general idea of transmuting, rather than limiting the text to allowing it only via I've proposed some alternative text above to kick of discussion about the best way to phrase such a guarantee. @rfcbot reviewed |
1c20573
to
8af820d
Compare
@rfcbot resolve concept-vs-method Though, other folks, please review the text to ensure it's still something with which you're ok. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
library/core/src/intrinsics.rs
Outdated
/// Transmuting pointers *to* integers in a `const` context is [undefined behavior][ub], | ||
/// unless the pointer was originally created by transmuting *from* an integer. | ||
/// (That includes this function specifically and helpers like [`invalid`][crate::ptr::invalid], | ||
/// but also semantically-equivalent conversions such as punning through `repr(C)` union 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.
/// Transmuting pointers *to* integers in a `const` context is [undefined behavior][ub], | |
/// unless the pointer was originally created by transmuting *from* an integer. | |
/// (That includes this function specifically and helpers like [`invalid`][crate::ptr::invalid], | |
/// but also semantically-equivalent conversions such as punning through `repr(C)` union fields.) | |
/// Transmuting pointers *to* integers in a `const` context is [undefined behavior][ub], | |
/// unless the pointer was originally created *from* an integer. | |
/// (The pointer can be created from an integer via integer-to-pointer casts, helpers like [`invalid`][crate::ptr::invalid], | |
/// this function, or semantically-equivalent conversions such as punning through `repr(C)` union fields.) |
We don't want to say that invalid
is a transmute. We just want to say that transmute(ptr::invalid(N)): *mut T
is allowed, as is transmute(Nusize): *mut T
.
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.
Wait, does "that includes" refer to "created by" or to "transmuting to"? It must be "created by" as otherwise invalid
can't be in the list, but then this doesn't cover union field punning from invalid
to an integer.
IMO this section shouldn't talk specifically about that anyway, that should fall out of the general principle that transmute
and union field punning are equivalent.
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 mention only [invalid
][crate::ptr::invalid] explicitly?
Something like:
unless the pointer was originally converted *from* an integer.
(for example with this function or [`invalid`][crate::ptr::invalid])
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.
I'm pretty sure we want to allow transmuting 16 as *const u8
back to an integer. There is really no reason not to.
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.
I would say that is converted from and integer
and therefore allowed.
Not sure how to write a concise description that makes it clear all the possibilities for this conversion are allowed.
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.
The parenthetical explains what it means to convert from an integer. So then if you think casting is converting from an integer, it should be listed. :)
8af820d
to
dc4e026
Compare
Applied @RalfJung's suggestions. |
(Re-nominated to encourage discussion of the exact text on Tuesday.) |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Oh, sorry, I didn't realize this was assigned to me... @bors r+ rollup |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#113510 (Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts.) - rust-lang#114412 (document our assumptions about symbols provided by the libc) - rust-lang#114813 (explain why we can mutate the FPU control word) - rust-lang#115523 (improve `AttrTokenStream`) - rust-lang#115536 (interpret: make MemPlace, Place, Operand types private to the interpreter) - rust-lang#115540 (Support debuginfo for custom MIR.) - rust-lang#115563 (llvm-wrapper: adapt for LLVM API change) r? `@ghost` `@rustbot` modify labels: rollup
see this zulip thread
r? @RalfJung
With this slice
Iterator
's should be able to be made const once the const Trait reimplementation is done.