diff options
| -rw-r--r-- | library/alloc/src/boxed.rs | 6 | ||||
| -rw-r--r-- | library/core/src/ptr/mod.rs | 8 |
2 files changed, 7 insertions, 7 deletions
diff --git a/library/alloc/src/boxed.rs b/library/alloc/src/boxed.rs index c543ee2d0c5..7fd91aba321 100644 --- a/library/alloc/src/boxed.rs +++ b/library/alloc/src/boxed.rs @@ -63,9 +63,9 @@ //! [`Global`] allocator with [`Layout::for_value(&*value)`]. //! //! For zero-sized values, the `Box` pointer still has to be [valid] for reads and writes and -//! sufficiently aligned. In particular, casting any aligned non-zero integer to a raw pointer -//! produces a valid pointer, but a pointer pointing into previously allocated memory that since got -//! freed is not valid. +//! sufficiently aligned. In particular, casting any aligned non-zero integer literal to a raw +//! pointer produces a valid pointer, but a pointer pointing into previously allocated memory that +//! since got freed is not valid. //! //! So long as `T: Sized`, a `Box<T>` is guaranteed to be represented //! as a single pointer and is also ABI-compatible with C pointers diff --git a/library/core/src/ptr/mod.rs b/library/core/src/ptr/mod.rs index 453621d9ead..243346a429a 100644 --- a/library/core/src/ptr/mod.rs +++ b/library/core/src/ptr/mod.rs @@ -21,10 +21,10 @@ //! within the bounds of a single allocated object. Note that in Rust, //! every (stack-allocated) variable is considered a separate allocated object. //! * Even for operations of [size zero][zst], the pointer must not be "dangling" in the sense of -//! pointing to deallocated memory. However, casting any non-zero integer to a pointer is valid -//! for zero-sized accesses. This corresponds to writing your own allocator; allocating zero-sized -//! objects is not very hard. In contrast, when you use the standard allocator, after memory got -//! deallocated, even zero-sized accesses to that memory are invalid. +//! pointing to deallocated memory. However, casting any non-zero integer literal to a pointer is +//! valid for zero-sized accesses. This corresponds to writing your own allocator; allocating +//! zero-sized objects is not very hard. In contrast, when you use the standard allocator, after +//! memory got deallocated, even zero-sized accesses to that memory are invalid. //! * All accesses performed by functions in this module are *non-atomic* in the sense //! of [atomic operations] used to synchronize between threads. This means it is //! undefined behavior to perform two concurrent accesses to the same location from different |