See https://github.com/rust-lang/rust/pull/63297#pullrequestreview-271172547 : I thought there was pretty much consensus that our integers do not have provenance, hence I wrote a note along those lines some time ago and it is in the
wrapping_offset docs these days. Was I moving too quick?
Was I moving too quick?
IIUC from the LLVM bug, LLVM does not support this yet, and it still miscompiles programs.
Although it appears that the intent is to support this at some point
There are some safe Rust programs that get "miscompiled" due to this, but I am not sure whether these are miscompilations or not
I also don't think anyone wants integers to carry pointer provenance in Rust, but given that there hasn't been a formal decision (e.g., by T-lang) and there are reasonable concerns about whether LLVM supports/will support that, we should probably be conservative in libstd docs, just as we are w.r.t. things like uninitialized integers.
but what else would we tell people that ask for cross-object arithmetic? "not possible"? I fear if we do that, they'll use
wrapping_offset as that's just so much easier to use.
Due to the current bugs, can we tell them that it is possible?
I don't want integers to carry provenance, but I don't think there is a reliable way to do this in Rust (or C or C++) today
I am not disagreeing. I am just saying I think the alternative is that people will do it anyway, and will notice it seems to work -- and they'll not e as conservative as they should be so even if the LLVM devs fix their stuff one day, this code will still be wrong.
It's an ungreat situation. Perhaps we can document the ptrtoint way as "not decided, may still be UB, but if anything will ever work it'll be this"
"ungreat", heh ;)
do you want to give a shot at updating the docs that way?
I don't think it'll be high priority enough for me to get to it soon-ish