Does setting a void * value to a intptr_t variable require an explicit cast?

I can't seem to make sense of a GCC compiler warning I get when I try to assign a void * value to a intptr_t variable. Specifically, when I compile with -std=c99 -pedantic, I get the following warning regarding the initialization of variable z on line 7:

warning: initialization makes integer from pointer without a cast [-Wint-conversion]

Here is the source code:

#include <stdint.h>

int main(void){
        unsigned int x = 42;
        void *y = &x;

        intptr_t z = y; /* warning: initialization makes integer from pointer without a cast [-Wint-conversion] */

        return 0;
}

Naturally, if I explicitly cast y to intptr_t then the warning disappears. However, I confused why the warning is present for implicit conversions when the whole purpose of intptr_t is in the conversion and manipulation of void * values.

From section 7.18.1.4 of the C99 standard:

The following type designates a signed 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:

intptr_t

Am I misinterpreting the standard, or is GCC simply overly pedantic in its "integer from pointer" check in this case?

Solution

Summing up! Apologies in advance for any errors — please leave me a comment.

In C99:

Any pointer can be converted to an integer type.¹
You might want to do that, e.g., if you are implementing your own operating system!
Conversions between pointers and integers can go horribly wrong,¹ so are usually not what you want.
Therefore, the compiler warns you when you convert pointers to integers without casting. This is not overly pedantic, but to save you from undefined behaviour.
intptr_t (and uintptr_t, and likewise throughout) is just an integer type,² so it is subject to the same risks as any other pointer-to-integer conversion. Therefore, you get the same warning.
However, with intptr_t, you at least know that the conversion from a pointer won't truncate any bits. So those are the types to use — with explicit casts — if you really need the integer values of pointers.
- The spec^{1, #6} says that
  
  ... the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined.
  
  With intptr_t, the result can be represented in the integer type. Therefore, the behaviour is not undefined, but merely implementation-defined. That is (as far as I know) why those types are safe to use for receiving values from pointers.

Edit

Reference 1, below, is part of section 6.3, "Conversions." The spec says:³

Several operators convert operand values from one type to another automatically. This subclause specifies the result required from such an implicit conversion...

and refers to section 6.5.4 for a discussion of explicit casts. Therefore, the discussion in Reference 1 indeed covers implicit casts from any pointer type to intptr_t. By my reading, then, an implicit cast from void * to intptr_t is legal, and has an implementation-defined result.^{1, 4}

Regarding whether the explicit cast should be used, gcc -pedantic thinks it should, and there must be a good reason! :) I personally agree that the explicit cast is more clear. I am also of the school of thought that code should compile without warnings if at all possible, so I would add the explicit cast if it were my code.

References

¹C99 draft (since I don't have a copy of the final spec), sec. 6.3.2.3 #5 and #6).

²Id., sec. 7.18.1.4

³Id., sec. 6.3

⁴Id., sec. 3.4.1, defines "implementation-defined behavior" as "unspecified behavior where each implementation documents how the choice is made." The implication is that the conversion is legal, but that the result may be different on one platform than on another.