about summary refs log tree commit diff
path: root/compiler/rustc_pattern_analysis/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2024-02-21 21:48:38 +0000
committerbors <bors@rust-lang.org>2024-02-21 21:48:38 +0000
commit3406ada96f8e16e49e947a91db3eba0db45245fa (patch)
treea587fbd99e1127cc7e7fb4690c05323cdb6e6ff1 /compiler/rustc_pattern_analysis/src
parentd7bd9cd469ff6871420007f091ef52fc32d2ca99 (diff)
parentb58f647d5488dce73bba517907c44af2c2a618c4 (diff)
downloadrust-3406ada96f8e16e49e947a91db3eba0db45245fa.tar.gz
rust-3406ada96f8e16e49e947a91db3eba0db45245fa.zip
Auto merge of #117658 - RalfJung:ptr-dangling, r=m-ou-se
rename ptr::invalid -> ptr::without_provenance

It has long bothered me that `ptr::invalid` returns a pointer that is actually valid for zero-sized memory accesses. In general, it doesn't even make sense to ask "is this pointer valid", you have to ask "is this pointer valid for a given memory access". We could say that a pointer is invalid if it is not valid for *any* memory access, but [the way this FCP is going](https://github.com/rust-lang/unsafe-code-guidelines/issues/472), it looks like *all* pointers will be valid for zero-sized memory accesses.

Two possible alternative names emerged as people's favorites:
1. Something involving `dangling`, in analogy to `NonNull::dangling`. To avoid inconsistency with the `NonNull` method, the address-taking method could be called `dangling_at(addr: usize) -> *const T`.
2. `without_provenance`, to be symmetric with the inverse operation `ptr.addr_without_provenance()` (currently still called `ptr.addr()` but probably going to be renamed)

I have no idea which one of these is better. I read [this comment](https://github.com/rust-lang/rust/pull/117658#issuecomment-1830934701) as expressing a slight preference for something like the second option, so I went for that. I'm happy to go with `dangling_at` as well.

Cc `@rust-lang/opsem`
Diffstat (limited to 'compiler/rustc_pattern_analysis/src')
0 files changed, 0 insertions, 0 deletions