Does going through uintptr_t bring any safety when casting a pointer type to uint64_t?

Question

Note that this is purely an academic question, from a language lawyer perspective. It's about the theoretically safest way to accomplish the conversion.

Suppose I have a void* and I need to convert it to a 64-bit integer. The reason is that this pointer holds the address of a faulting instruction; I wish to report this to my backend to be logged, and I use a fixed-size protocol - so I have precisely 64 bits to use for the address.

The cast will of course be implementation defined. I know my platform (64-bit Windows) allows this conversion, so in practice it's fine to just reinterpret_cast(address).

But I'm wondering: from a theoretical standpoint, is it any safer to first convert to uintptr_t? That is: static_cast(reinterpret_cast(address)). https://en.cppreference.com/w/cpp/language/reinterpret_cast says (emphasis mine):

Unlike static_cast, but like const_cast, the reinterpret_cast expression does not compile to any CPU instructions (except when converting between integers and pointers or on obscure architectures where pointer representation depends on its type).

So, in theory, pointer representation is not defined to be anything in particular; going from pointer to uintptr_t might theoretically perform a conversion of some kind to make the pointer representable as an integer. After that, I forcibly extract the lower 64 bits. Whereas just directly casting to uint64_t would not trigger the conversion mentioned above, and so I'd get a different result.

Is my interpretation correct, or is there no difference whatsoever between the two casts in theory as well?

FWIW, on a 32-bit system, apparently the widening conversion to unsigned 64-bit could sign-extend, as in this case. But on 64-bit I shouldn't have that issue.

user_787480 · Answer

You’re parsing that (shockingly informal, for cppreference) paragraph too closely. The thing it’s trying to get at is simply that other casts potentially involve conversion operations (float/int stuff, sign extension, pointer adjustment), whereas reinterpret_cast has the flavor of direct reuse of the bits.

If you reinterpret a pointer as an integer and the integer type is not large enough, you get a compile-time error. If it is large enough, you’re fine. There’s nothing magical about uintptr_t other than the guarantee that (if it exists) it’s large enough, and if you then re-cast to a smaller type you lose that anyway. Either 64 bits is enough, in which case you get the same guarantees with either type, or it’s not, and you’re screwed no matter what you do. And if your implementation is willing to do something weird inside reinterpret_cast, which might give different results than (say) bit_cast, neither method will guarantee nor prevent that.

That’s not to say the two are guaranteed identical, of course. Consider a DS9k-ish architecture with 32-bit pointers, where reinterpret_cast of a pointer to a uint64_t resulted in the pointer bits being duplicated in the low and high words. There you’d get both copies if you went directly to a uint64_t, and zeros in the top half if you went through a 32-bit uintptr_t. In that case, which one was “right” would be a matter of personal opinion.

Does going through uintptr_t bring any safety when casting a pointer type to uint64_t?

1 Answers