1
Fork 0

explicitly talk about integer literals

This commit is contained in:
Ralf Jung 2020-10-13 09:30:09 +02:00
parent c555aabc5b
commit 0f572a9810
2 changed files with 7 additions and 7 deletions

View file

@ -63,9 +63,9 @@
//! [`Global`] allocator with [`Layout::for_value(&*value)`]. //! [`Global`] allocator with [`Layout::for_value(&*value)`].
//! //!
//! For zero-sized values, the `Box` pointer still has to be [valid] for reads and writes and //! 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 //! sufficiently aligned. In particular, casting any aligned non-zero integer literal to a raw
//! produces a valid pointer, but a pointer pointing into previously allocated memory that since got //! pointer produces a valid pointer, but a pointer pointing into previously allocated memory that
//! freed is not valid. //! since got freed is not valid.
//! //!
//! So long as `T: Sized`, a `Box<T>` is guaranteed to be represented //! 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 //! as a single pointer and is also ABI-compatible with C pointers

View file

@ -21,10 +21,10 @@
//! within the bounds of a single allocated object. Note that in Rust, //! within the bounds of a single allocated object. Note that in Rust,
//! every (stack-allocated) variable is considered a separate allocated object. //! 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 //! * 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 //! pointing to deallocated memory. However, casting any non-zero integer literal to a pointer is
//! for zero-sized accesses. This corresponds to writing your own allocator; allocating zero-sized //! valid for zero-sized accesses. This corresponds to writing your own allocator; allocating
//! objects is not very hard. In contrast, when you use the standard allocator, after memory got //! zero-sized objects is not very hard. In contrast, when you use the standard allocator, after
//! deallocated, even zero-sized accesses to that memory are invalid. //! 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 //! * 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 //! 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 //! undefined behavior to perform two concurrent accesses to the same location from different