|
200 | 200 | //!
|
201 | 201 | //! But it *is* still sound to:
|
202 | 202 | //!
|
203 |
| -//! * Create a pointer without provenance from just an address (see [`ptr::dangling`]). Such a |
| 203 | +//! * Create a pointer without provenance from just an address (see [`without_provenance`]). Such a |
204 | 204 | //! pointer cannot be used for memory accesses (except for zero-sized accesses). This can still be
|
205 | 205 | //! useful for sentinel values like `null` *or* to represent a tagged pointer that will never be
|
206 | 206 | //! dereferenceable. In general, it is always sound for an integer to pretend to be a pointer "for
|
|
314 | 314 | //! }
|
315 | 315 | //! ```
|
316 | 316 | //!
|
317 |
| -//! (Yes, if you've been using AtomicUsize for pointers in concurrent datastructures, you should |
318 |
| -//! be using AtomicPtr instead. If that messes up the way you atomically manipulate pointers, |
| 317 | +//! (Yes, if you've been using [`AtomicUsize`] for pointers in concurrent datastructures, you should |
| 318 | +//! be using [`AtomicPtr`] instead. If that messes up the way you atomically manipulate pointers, |
319 | 319 | //! we would like to know why, and what needs to be done to fix it.)
|
320 | 320 | //!
|
321 | 321 | //! Situations where a valid pointer *must* be created from just an address, such as baremetal code
|
|
381 | 381 | //! [`with_addr`]: pointer::with_addr
|
382 | 382 | //! [`map_addr`]: pointer::map_addr
|
383 | 383 | //! [`addr`]: pointer::addr
|
384 |
| -//! [`ptr::dangling`]: core::ptr::dangling |
| 384 | +//! [`AtomicUsize`]: crate::sync::atomic::AtomicUsize |
| 385 | +//! [`AtomicPtr`]: crate::sync::atomic::AtomicPtr |
385 | 386 | //! [`expose_provenance`]: pointer::expose_provenance
|
386 | 387 | //! [`with_exposed_provenance`]: with_exposed_provenance
|
387 | 388 | //! [Miri]: https://github.com/rust-lang/miri
|
|
0 commit comments