Pointer comparisons ignore provenance [LWN.net]

Pointer comparisons ignore provenance

Posted Oct 19, 2024 19:46 UTC (Sat) by NYKevin (subscriber, #129325)
In reply to: Pointer comparisons ignore provenance by NYKevin
Parent article: Zapping pointers out of thin air

NB: This is assuming you're talking about my (1) and (2), and not Tobu's, because that seemed obviously wrong to me. Tobu's (1) requires that casting both pointers to usize and comparing them produces the same result, whereas (2) permits it to non-deterministically return false in cases where the provenance does not match, so (2) allows optimizations that (1) forbids. It is certainly not the case that compilers will prefer to leave optimizations on the table if they are permitted by whatever standard we end up adopting.

to post comments

Pointer comparisons ignore provenance

Posted Oct 20, 2024 8:43 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

Unsurprisingly (surely even to you?) when I respond to Tobu, I am referring to what Tobu wrote.

If you want your numbering to exclusively refer to a specific thing you once wrote somewhere you're going to need much bigger numbers, I recommend 128-bit UUIDs for this work, however, since we're talking among people, I would suggest that naming things, though it has some undesirable quirks, is preferable, that's why the "worst case" provenance model offered in Rust and the default provenance proposed for C is referred to as "PNVI-ae-udi" rather than some hard to distinguish UUID, when I typo'd that name earlier everybody still knew what I meant.

As to the substance: Useless "optimisations" have to be painstakingly eliminated so there's no reason to ask for them knowing that you won't use them. Yes it is likely that LLVM will decide they can "optimise" ptrA == ptrB in some way that's not helpful, and if they want to do that Rust will just emit the IR for ptrA.addr() == ptrB.addr() instead so that it gets the required semantics. Today it doesn't matter because (as I wrote) there's an LLVM bug and as a result LLVM can believe that for two machine integers A, B A != B but A - B = 0 which is nonsense and the LLVM devs know it's nonsense but it's a consequence of this sort of "optimisation".