Skip to content

Commit f1bdbd6

Browse files
Rollup merge of rust-lang#97482 - RalfJung:ptr-invalid, r=thomcc
ptr::invalid is not equivalent to a int2ptr cast I just realized I forgot to update these docs when adding `from_exposed_addr`. Right now the docs say `invalid` and `from_exposed_addr` are both equivalent to a cast, and that is clearly not what we want. Cc ``@Gankra``
2 parents 3c37221 + 5aa4d25 commit f1bdbd6

File tree

1 file changed

+7
-6
lines changed

1 file changed

+7
-6
lines changed

Diff for: core/src/ptr/mod.rs

+7-6
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@
2626
//! some memory happens to exist at that address and gets deallocated. This corresponds to writing
2727
//! your own allocator: allocating zero-sized objects is not very hard. The canonical way to
2828
//! obtain a pointer that is valid for zero-sized accesses is [`NonNull::dangling`].
29+
//FIXME: mention `ptr::invalid` above, once it is stable.
2930
//! * All accesses performed by functions in this module are *non-atomic* in the sense
3031
//! of [atomic operations] used to synchronize between threads. This means it is
3132
//! undefined behavior to perform two concurrent accesses to the same location from different
@@ -557,16 +558,16 @@ pub const fn null_mut<T>() -> *mut T {
557558

558559
/// Creates an invalid pointer with the given address.
559560
///
560-
/// This is *currently* equivalent to `addr as *const T` but it expresses the intended semantic
561-
/// more clearly, and may become important under future memory models.
561+
/// This is different from `addr as *const T`, which creates a pointer that picks up a previously
562+
/// exposed provenance. See [`from_exposed_addr`] for more details on that operation.
562563
///
563564
/// The module's top-level documentation discusses the precise meaning of an "invalid"
564565
/// pointer but essentially this expresses that the pointer is not associated
565566
/// with any actual allocation and is little more than a usize address in disguise.
566567
///
567568
/// This pointer will have no provenance associated with it and is therefore
568569
/// UB to read/write/offset. This mostly exists to facilitate things
569-
/// like ptr::null and NonNull::dangling which make invalid pointers.
570+
/// like `ptr::null` and `NonNull::dangling` which make invalid pointers.
570571
///
571572
/// (Standard "Zero-Sized-Types get to cheat and lie" caveats apply, although it
572573
/// may be desirable to give them their own API just to make that 100% clear.)
@@ -588,16 +589,16 @@ pub const fn invalid<T>(addr: usize) -> *const T {
588589

589590
/// Creates an invalid mutable pointer with the given address.
590591
///
591-
/// This is *currently* equivalent to `addr as *mut T` but it expresses the intended semantic
592-
/// more clearly, and may become important under future memory models.
592+
/// This is different from `addr as *mut T`, which creates a pointer that picks up a previously
593+
/// exposed provenance. See [`from_exposed_addr_mut`] for more details on that operation.
593594
///
594595
/// The module's top-level documentation discusses the precise meaning of an "invalid"
595596
/// pointer but essentially this expresses that the pointer is not associated
596597
/// with any actual allocation and is little more than a usize address in disguise.
597598
///
598599
/// This pointer will have no provenance associated with it and is therefore
599600
/// UB to read/write/offset. This mostly exists to facilitate things
600-
/// like ptr::null and NonNull::dangling which make invalid pointers.
601+
/// like `ptr::null` and `NonNull::dangling` which make invalid pointers.
601602
///
602603
/// (Standard "Zero-Sized-Types get to cheat and lie" caveats apply, although it
603604
/// may be desirable to give them their own API just to make that 100% clear.)

0 commit comments

Comments
 (0)