Skip to content

Commit 0f572a9

Browse files
committed
explicitly talk about integer literals
1 parent c555aab commit 0f572a9

File tree

2 files changed

+7
-7
lines changed

2 files changed

+7
-7
lines changed

library/alloc/src/boxed.rs

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -63,9 +63,9 @@
6363
//! [`Global`] allocator with [`Layout::for_value(&*value)`].
6464
//!
6565
//! For zero-sized values, the `Box` pointer still has to be [valid] for reads and writes and
66-
//! sufficiently aligned. In particular, casting any aligned non-zero integer to a raw pointer
67-
//! produces a valid pointer, but a pointer pointing into previously allocated memory that since got
68-
//! freed is not valid.
66+
//! sufficiently aligned. In particular, casting any aligned non-zero integer literal to a raw
67+
//! pointer produces a valid pointer, but a pointer pointing into previously allocated memory that
68+
//! since got freed is not valid.
6969
//!
7070
//! So long as `T: Sized`, a `Box<T>` is guaranteed to be represented
7171
//! as a single pointer and is also ABI-compatible with C pointers

library/core/src/ptr/mod.rs

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -21,10 +21,10 @@
2121
//! within the bounds of a single allocated object. Note that in Rust,
2222
//! every (stack-allocated) variable is considered a separate allocated object.
2323
//! * Even for operations of [size zero][zst], the pointer must not be "dangling" in the sense of
24-
//! pointing to deallocated memory. However, casting any non-zero integer to a pointer is valid
25-
//! for zero-sized accesses. This corresponds to writing your own allocator; allocating zero-sized
26-
//! objects is not very hard. In contrast, when you use the standard allocator, after memory got
27-
//! deallocated, even zero-sized accesses to that memory are invalid.
24+
//! pointing to deallocated memory. However, casting any non-zero integer literal to a pointer is
25+
//! valid for zero-sized accesses. This corresponds to writing your own allocator; allocating
26+
//! zero-sized objects is not very hard. In contrast, when you use the standard allocator, after
27+
//! memory got deallocated, even zero-sized accesses to that memory are invalid.
2828
//! * All accesses performed by functions in this module are *non-atomic* in the sense
2929
//! of [atomic operations] used to synchronize between threads. This means it is
3030
//! undefined behavior to perform two concurrent accesses to the same location from different

0 commit comments

Comments
 (0)