将非`void`指针转换为`uintptr_t`，反之亦然

Question

There are two related C standard rules:

C99 standard, 6.3.2.3 :

A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.

And 7.20.1.4 :

The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer: uintptr_t

It means, that the following code is compliant:

int *p = NULL;
void *q = (void*)p;
uintptr_t s = (uintptr_t)q;

But does it really need the two-step cast? Will the compiler perform an implicit intermediate cast if doing something like:

int *p = NULL;
uintptr_t s = (uintptr_t)p;

(Well, it probably will on most compilers, but my question is about standard compliance)

Answer 1

I wouldn't risk it. The standard makes it abundantly clear what is allowed and what is not allowed.

Writing uintptr_t s = (uintptr_t)(void*)p; signals to a reader of your code that you know what you're doing.

Answer 2

Any quality general-purpose implementation will process conversions between uintptr_t and a non-void type as if they'd been converted through void* . The Standard treats behavior in this situation, and many others involving pointers, as a quality-of-implementation issue, and expects that people who are seeking to write quality implementations will be able to recognize situations where there's one obvious, sensible, and useful way for a program to behave without the Standard having to explicitly enumerate them all. They also recognize that it's possible to produce an implementation which is conforming but of such poor quality as to be useless.

Although it would be possible to have an implementation where conversions between uintptr_t and any non-void pointer type behave in any arbitrary fashion of the implementer's choosing, anyone who produces an implementation where such conversions don't work in the typical fashion, and who fails to document a good reason for such difference, should be recognized as a vandal who is trying to undermine the language with their poor quality implementation. Programmers should feel no obligation to appease such behavior; unless or until it is seen for what is is, it will get worse and worse until the language becomes totally useless.