Is "0xffffffff00000000" an indication of a mix-up between 32-bit and 64-bit compilations?

Question

I compiled Qt in 64 bit. My code is also compiled in 64 bit. I initialize a (pointer) member variable to zero. When I inspect it, XCode tells me that its value is not 0 but 0xffffffff00000000.

Is this a sign of a mix-up between 32 and 64? How might the 32 bit initialization have crept into the executable when both the library and my code have 'g++ .. -arch x86_64 -Xarch_x86_64 .. '? In case it matters, I am on Snow Leopard.

----Begin-Edit----

I appreciate finding out after all these years that the standard does not impose the value 0x00..00 when one assigns 0 to a pointer, but this is not the issue in this case.

#include <stdio.h>

int main()
{
    const char * c = "Foo";
    printf("Pointers in this executable use %lu bytes.\n", sizeof(c));
    void * z = 0;
    printf("A zero pointer in this executable is %p\n", z);
}

If I save the code above in '32_or_64.cpp' then compile it with 'g++ -arch i386 32_or_64.cpp', I get

Pointers in this executable use 4 bytes.
A zero pointer in this executable is 0x0

If I compile it with 'g++ -arch x86_64 32_or_64.cpp', I get

Pointers in this executable use 8 bytes.
A zero pointer in this executable is 0x0

If you believe that this does not establish that 0 on my particular configuration should not let me see precisely 0 when debugging in x86_64, please point it out. Otherwise, debating 'null' is a wonderful discussion, but an irrelevant one in this thread.

----End-Edit----

Answer 1

Update: this explanation seems bogus in the light of π's edit. But you might find it interesting anyway.

---

In C-like languages, a pointer value written as 0 in the source code is just a convention for specifying a null pointer. A null pointer is a pointer that is guaranteed not to point to any object, and it is defined to test equal to the integer zero, but it doesn't need to have the same internal representation as the integer zero. Null pointers can have a variety of representations, depending on the architecture, or even on the type of the pointer.

The use of 0 to mean "null pointer" is perhaps an unfortunate convention; the level of confusion it causes is perhaps best indicated by the length of Steve Summit's C programming language FAQ on the subject.

hexa's comment is, I think, evidence of the difficulty of understanding this convention. The trouble is that there are three ideas to be separated:

• The concept of a null pointer: a pointer that's distinct from a pointer to any object.
• The representation of a null pointer on a machine (in some cases by the address 0x00000000, but that's not something you can or should rely on).
• How you can create and test null pointers in C-like languages (by using a null pointer constant like 0 or NULL).

Here's the C++ standard, section 4.10:

A null pointer constant is an integral constant expression rvalue of integer type that evaluates to zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function type. Two null pointer values of the same type shall compare equal.

This guarantees that you can create a null pointer using the constant 0, and test whether a pointer is null by comparison with 0, but says nothing about the machine representation of the null pointer.