-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 that Unique::empty() and NonNull::dangling() aren't sentinel values #52508
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
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.
r=me with the nit fixed
src/libcore/ptr.rs
Outdated
/// | ||
/// Note that the pointer value may potentially represent a valid pointer to | ||
/// a `T`, which means this must not be used as a "not yet initialized" | ||
/// sentinel value. Types that lazily allocate must track initialized cells |
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.
nit: s/initialized cells/initialization
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.
Done.
… values The documentation of Unique::empty() and NonNull::dangling() could potentially suggest that they work as sentinel values indicating a not-yet-initialized pointer. However, they both declare a non-null pointer equal to the alignment of the type, which could potentially reference a valid value of that type (specifically, the first such valid value in memory). Explicitly document that the return value of these functions does not work as a sentinel value.
31e97d1
to
ce75632
Compare
@kennytm |
@kennytm If we don't have an immediate fix, we should revert them. |
I disagree with reverting, at least #51901 fixed a much more real bug. |
Ah, fair enough. But we do need a fix for them. @kennytm Would the solution I proposed of using |
@joshtriplett If the compiler doesn't assume (A properly allocated |
@joshtriplett Ping, are you going to do this |
📌 Commit ce75632 has been approved by |
@bors rollup |
… r=Mark-Simulacrum Document that Unique::empty() and NonNull::dangling() aren't sentinel values The documentation of Unique::empty() and NonNull::dangling() could potentially suggest that they work as sentinel values indicating a not-yet-initialized pointer. However, they both declare a non-null pointer equal to the alignment of the type, which could potentially reference a valid value of that type (specifically, the first such valid value in memory). Explicitly document that the return value of these functions does not work as a sentinel value.
Which advantage does |
@RalfJung |
@joshtriplett I assume you mean Cc @eddyb |
We definitely can't extend the niche of |
I can prepare a PR today or tmr. |
… r=Mark-Simulacrum Document that Unique::empty() and NonNull::dangling() aren't sentinel values The documentation of Unique::empty() and NonNull::dangling() could potentially suggest that they work as sentinel values indicating a not-yet-initialized pointer. However, they both declare a non-null pointer equal to the alignment of the type, which could potentially reference a valid value of that type (specifically, the first such valid value in memory). Explicitly document that the return value of these functions does not work as a sentinel value.
Rollup of 11 pull requests Successful merges: - #51807 (Deprecation of str::slice_unchecked(_mut)) - #52051 (mem::swap the obvious way for types smaller than the SIMD optimization's block size) - #52465 (Add CI test harness for `thumb*` targets. [IRR-2018-embedded]) - #52507 (Reword when `_` couldn't be inferred) - #52508 (Document that Unique::empty() and NonNull::dangling() aren't sentinel values) - #52521 (Fix links in rustdoc book.) - #52581 (Avoid using `#[macro_export]` for documenting builtin macros) - #52582 (Typo) - #52587 (Add missing backtick in UniversalRegions doc comment) - #52594 (Run the error index tool against the sysroot libdir) - #52615 (Added new lines to .gitignore.)
Done: #52637 |
Ah-- I had been under the assumption that |
Yes, this isn't the case: |
Don't use NonNull::dangling as sentinel value in Rc, Arc Instead, rely on alignment and use usize::MAX as sentinel. Cc rust-lang#52508 r? @joshtriplett
Sorry I’m only seeing this now, but I’m surprised by this change and not sure I agree with it. |
@SimonSapin A discussion on Discord led us to the conclusion that 0x(alignment) is potentially a valid pointer, so using it as a sentinel value may lead to incorrect behavior when such a pointer is legitimately passed. |
So should we open an issue for If this is reoccurring, should |
Vec never does something like |
Yes, because of the separate |
Ah ok. Branching on equality to Still, does the pointer in |
The documentation of Unique::empty() and NonNull::dangling() could
potentially suggest that they work as sentinel values indicating a
not-yet-initialized pointer. However, they both declare a non-null
pointer equal to the alignment of the type, which could potentially
reference a valid value of that type (specifically, the first such valid
value in memory). Explicitly document that the return value of these
functions does not work as a sentinel value.