-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Document that Unique::empty() and NonNull::dangling() aren't sentinel values #52508
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.