Skip to content

Commit a0ea69f

Browse files
authored
Rollup merge of rust-lang#129652 - RalfJung:ptr-to-ref, r=traviscross
fix Pointer to reference conversion docs The aliasing rules documented in rust-lang#128157 are wrong, this fixes them.
2 parents c7cbb41 + c108af0 commit a0ea69f

File tree

1 file changed

+15
-23
lines changed

1 file changed

+15
-23
lines changed

core/src/ptr/mod.rs

+15-23
Original file line numberDiff line numberDiff line change
@@ -57,50 +57,42 @@
5757
//! [`NonNull::dangling`] in such cases.
5858
//!
5959
//! ## Pointer to reference conversion
60-
//! When converting a pointer to a reference `&T` using `&*`,
60+
//!
61+
//! When converting a pointer to a reference (e.g. via `&*ptr` or `&mut *ptr`),
6162
//! there are several rules that must be followed:
6263
//!
6364
//! * The pointer must be properly aligned.
6465
//!
65-
// some microprocessors may use address 0 for an interrupt vector.
66-
// users of these microprocessors must always read/write address 0 through
67-
// a raw pointer, not a reference.
6866
//! * It must be non-null.
6967
//!
7068
//! * It must be "dereferenceable" in the sense defined above.
7169
//!
72-
//! * The pointer must point to a valid value of type `T`.
73-
//! This means that the created reference can only refer to
74-
//! uninitialized memory through careful use of `MaybeUninit`,
75-
//! or if the uninitialized memory is entirely contained within
76-
//! padding bytes, since
77-
//! [padding has the same validity invariant as `MaybeUninit`][ucg-pad].
78-
//!
79-
//! * You must enforce Rust's aliasing rules, since the lifetime of the
80-
//! created reference is arbitrarily chosen,
81-
//! and does not necessarily reflect the actual lifetime of the data.
82-
//! In particular, while this reference exists,
83-
//! the memory the pointer points to must
84-
//! not get accessed (read or written) through any raw pointer,
85-
//! except for data inside an `UnsafeCell`.
86-
//! Note that aliased writes are always UB for mutable references,
87-
//! even if they only modify `UnsafeCell` data.
70+
//! * The pointer must point to a [valid value] of type `T`.
71+
//!
72+
//! * You must enforce Rust's aliasing rules. The exact aliasing rules are not decided yet, so we
73+
//! only give a rough overview here. The rules also depend on whether a mutable or a shared
74+
//! reference is being created.
75+
//! * When creating a mutable reference, then while this reference exists, the memory it points to
76+
//! must not get accessed (read or written) through any other pointer or reference not derived
77+
//! from this reference.
78+
//! * When creating a shared reference, then while this reference exists, the memory it points to
79+
//! must not get mutated (except inside `UnsafeCell`).
8880
//!
8981
//! If a pointer follows all of these rules, it is said to be
90-
//! *convertible to a reference*.
82+
//! *convertible to a (mutable or shared) reference*.
9183
// ^ we use this term instead of saying that the produced reference must
9284
// be valid, as the validity of a reference is easily confused for the
9385
// validity of the thing it refers to, and while the two concepts are
9486
// closly related, they are not identical.
9587
//!
96-
//! These apply even if the result is unused!
88+
//! These rules apply even if the result is unused!
9789
//! (The part about being initialized is not yet fully decided, but until
9890
//! it is, the only safe approach is to ensure that they are indeed initialized.)
9991
//!
10092
//! An example of the implications of the above rules is that an expression such
10193
//! as `unsafe { &*(0 as *const u8) }` is Immediate Undefined Behavior.
10294
//!
103-
//! [ucgpad]: https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#padding
95+
//! [valid value]: ../../reference/behavior-considered-undefined.html#invalid-values
10496
//!
10597
//! ## Allocated object
10698
//!

0 commit comments

Comments
 (0)