In intent and in current practice, is it valid to compare pointers to potentially-unrelated objects using
<=. In particular, is this valid?: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bdc00ec41449ab4eb285f96cc0ba3e39
Also, where are such things (to be) documented?
You can run code under miri in the playground to check what's currently supported.
Once layout and validity are rfc'ed we'll probably start with a model for MIR and move towards stacked borrows afterwards. We'll have to deal with pointer comparisons and provenance along the way.
Interesting. I'll try it (though t's not clear to me that MIRI's interpretation is equivalent to what LLVM would generate. In fact I think it's unlikely they're equivalent).
So, is it the case that right now that code is literally undefined behavior because nobody has even tried to define it?
comparison of pointers is one of those things where Miri is very limited in its support currently
and also, it is an open question in every formal model that I know of
the intent is clearly that it is defined (as in, not UB), because it is allowed in safe code
and in the most elaborate model, it is indeed not UB -- however, under some circumstances pointer comparison (not just
< but also
==) is nondeterministic, meaning comparing the same two pointers multiple times can yield a different result
the intent in LLVM is for it to be deterministic, but so far nobody has demonstrated a way to actually model that (and maintain the desired optimizations)
if you want to be on the safe side model-wise, cast the pointers to
usize and compare those. then everyone agrees that behavior is defined and deterministic.
@RalfJ In an ABI where the upper bits of pointers are used to store authentication information,
a < b doesn't imply that
(a as usize) < (b as usize) unless the
as usize conversion masks those bits in the same way that a
a < b pointer comparison would; but if that kind of masking were to be done then
p as usize wouldn't be equivalent to
(uintptr_t)p in C (IIUC). That's why I'm trying to avoid converting to
Based on the current discussion, for the use case that motivated me to start this thread, I'm going to switch away from the scheme that I was planning to use that required pointer ordering comparisons in factor of explicitly tagging which buffers are overlapping. Thanks for the responses!
I have to admit I gave no thought to ABIs that encode things in the upper bits of pointers. There are already enough open questions without such extra constraints.^^
Here is a summary of one such platform (ARMv8.3): https://lwn.net/Articles/718888/
thanks for the pointer!