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