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 Oh, well, the difficult part of memmove is that if the destination pointer points into the same array or aggregate object as the source pointer, but further down, you need to copy starting at the end and moving toward the beginning. But comparing unrelated pointers is undefined behavior (§6.5.8 of the ISO 9899:202x draft at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf) and so you really, really don't want to do that as the first step in your memmove.
However, uintptr_t allows you to do the comparison safely.
@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 I don't see how you can use it to implement memmove. uintptr_t could work also in CHERI, but not in the way they implemented it as a capability-carrying fake pointer type.