Alyssa the Kate
Aria DesiresMy baby is stable in Rust!!! Strict Provenance BAYBEEEE
https://doc.rust-lang.org/std/ptr/index.html#strict-provenance
PolyWolf@Gankra HECK YEAH!!!!!!!!
lebout2canap ⏚
Firstyear@Gankra Great work!
no, more mr. nice guy!@Gankra hell yeah hell yeah hell yeah
Graydon Hoare@Gankra Congratulations!
Adador@Gankra congrats!
Mae@Gankra it's really late, so maybe I just need to sleep, but I'm a bit confused on the idea of exposed provenances. Doesn't
> The compiler will do its best to pick the right provenance for you, but currently we cannot provide any guarantees about which provenance the resulting pointer will have.
Imply that any use of the resulting pointer, other than the uses already covered by `without_provenance` is UB?
> The compiler will do its best to pick the right provenance for you, but currently we cannot provide any guarantees about which provenance the resulting pointer will have.
Imply that any use of the resulting pointer, other than the uses already covered by `without_provenance` is UB?
dana 
Ted Mielczarek@Gankra awesome! Great work, as usual!
David Chisnall (*Now with 50% more sarcasm!*)@Gankra For anyone wondering why I am excited by this:
This is exactly how we lower intptr_t to LLVM IR in CHERI C/C++. Unlike the C/C++ version, the Rust surface-level syntax is unambiguous and clear. This should make writing CHERI-compatible unsafe Rust much cleaner (safe Rust is trivial to lower to CHERI already).
Gabriele Svelto [moved]@Gankra congratulations! 👏
chrysn@Gankra Will this also help with Harvard architecture support, where a pointer to ROM (whose numeric value may be identical to a RAM pointer with completely different meaning) could now carry their address bus in their provenance?
Either way: Great to have this in!
Either way: Great to have this in!
@chrysn its a separate issue mostly, see https://github.com/rust-lang/rust/issues/95489
