Should not use transmute to cast between pointers and integers

[programmerjake]

Pointer to integer transmutes are almost certainly UB if you want to convert the resulting integer to a valid pointer again...you need a explicit pointer cast operation instead.
rust-lang/unsafe-code-guidelines#286

imho integer to pointer transmutes should be avoided too (even though they aren't necessarily UB), to go along with avoiding pointer to integer transmutes.

See also: #287

[calebzulawski]

There's nothing wrong with actually casting (or transmuting) pointers, just using them. My understanding is that ptr as isize as *const T can't be dereferenced; there's nothing special about as vs transmute.

[Lokathor]

there is though

[calebzulawski]

Is there? as uses inttoptr, but it doesn't add the dereferenceable metadata. I agree we should use a cast intrinsic (for better codegen and readability), but either way there is no impact on provenance. rust-lang/rust#95228 calls out int as ptr as also being invalid.

[calebzulawski]

As far as I can tell, only with_addr or some wrapping_offset games are the only ways to make valid dereferenceable pointers out of integers--no cast will do it.

[thomcc]

ptr as int is ptr::expose_addr, which exposes the pointer. On platforms that allow it (which doesn't include inside miri, and may not include CHERI), if you haven't violated that provenance, this may allow converting back to the original pointer with the opposite as cast.

[calebzulawski]

Interesting. That must be the distinction I missed. Does LLVM even support this? The tracking issue for strict provenance implies this isn't valid at all, but I suppose this is saying that violating strict provenance isn't necessarily UB.

[programmerjake]

Interesting. That must be the distinction I missed. Does LLVM even support this?

yes. casting int <-> ptr has been part of C for years...iirc it is part of the original C spec.

The tracking issue for strict provenance implies this isn't valid at all, but I suppose this is saying that violating strict provenance isn't necessarily UB.

yes, strict provenance is intended to codify a simple-to-understand useful subset of what's considered valid -- int <-> pointer casting currently has ill-defined semantics -- C is currently trying to decide which formal model they use to describe it.

[calebzulawski]

Opened rust-lang/rust#98441

[RalfJung]

ptr as int is ptr::expose_addr, which exposes the pointer. On platforms that allow it (which doesn't include inside miri, and may not include CHERI), if you haven't violated that provenance, this may allow converting back to the original pointer with the opposite as cast.

FWIW, Miri actually does support this, but you lose precision -- as in, Miri might miss some UB when you do that.

Does LLVM even support this?

LLVM does not say what its ptr2int and int2ptr cast and transmute semantics are. And the implied semantics (by observing what optimizations do) are inconsistent -- they turn well-defined programs into UB.
So, looking to LLVM for guidance here is futile.

See my recent blog post for a lot more details on all that.

[calebzulawski]

Fixed in #287