rename ptr::invalid -> ptr::without_provenance by RalfJung · Pull Request #117658 · rust-lang/rust (original) (raw)

it seems more important to warn about the fact that this pointer cannot be used to access any memory than to be consistent with the inverse function

👍 to this.

I share the sentiment of not feeling great about either of lossy_addr or bare_addr.

Ralf's comment in rust-lang/unsafe-code-guidelines#478 (comment) caught my eye: I sometimes call them "(raw) integer pointers", but that doesn't really fit the pattern here.

I wonder if there is a way to lean into the interpretation of these being integers dressed as pointers, not so much pointers referring to some (invalid/dangling) "address".

What I mean is going even further than ptr.numerical_addr() / ptr::from_num{ber,erical_addr}, as these names still overly emphasize an address-ness which is not really there. If Ralf calls them an "integer pointer", maybe they're rather a "pointy integer".

pub mod ptr { pub fn pointy_integer(value: usize) - > *const T; pub fn pointy_integer_mut(value: usize) - > *mut T; }

The thing to figure out would be whether a "pointy integer" is the thing you get back from ptr::pointy_integer(value) (integer dressed as a pointer), or the thing you get back from ptr.expose_addr() (pointer dressed as an integer). To me, using "address" to describe the latter makes sense, and that leaves "pointy integer" unambiguously describing the former.