|
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