is it defined behavior in c to:
cast my pointer to uintptr_t
split it and assign across those two fields
and later in another function:
bitwise join the two fields in a uintptr_t
cast the result back to the original pointer type that i've allocated beforehand
since the value representation should be the same after rebuilding the uintptr, and uintptr is defined as surviving roundtrips, i think it's all good?
@navi Yes, these are the things which uintptr is for. (I have heard the absurd claim that because the standard only says that the pointer converted back compares equal, it is not guaranteed that you can actually use it. TS 6010 would have made it clearly legal.)
@uecker @navi This definitely will not work under CHERI, but the C standard isn't really written to support environments like CHERI, and obviously there would be significant disadvantages to doing so.
A different thing you can do with uintptr_t, one which doesn't require this kind of round-trip, is to write a portable implementation of a function like memmove. It isn't needed to write memmove itself, because you can just call the standard memmove, but it turns out to be helpful for things like bitblt.
@uecker @navi In capability systems where you can't "forge" capabilities by uttering a magical bit string in the way you're advocating, you can provide features like garbage collection and mandatory access control, which are pretty major benefits. The question then is to what degree you can make them compatible with existing software like the FreeBSD kernel, and the #CHERI folks have done some amazing work there.
@xentrac @navi It would not work by creating a capability from scratch, but looking it up in a list of previously exposed capabilities. So you still have all benefits. Another point is that you can write software that uses "uintptr_t" only in a CHERI-compatible way using actual pointers, while software that needs to escape from strict pointer semantics can not be written differently. So while I understand why CHERI does this, I think it is unfortunate.
@xentrac @navi Yes, the thing is, capability-based systems could support this by recovering the capability when back-converting to the pointer type. If they can't I think they should not have uintptr_t.