是“0xffffffff00000000” 32 位和 64 位编译之间是否存在混淆？
我用64位编译了Qt。我的代码也是用 64 位编译的。我将（指针）成员变量初始化为零。当我检查它时，XCode 告诉我它的值不是 0，而是 0xffffffff00000000。
这是 32 和 64 混淆的迹象吗？当库和我的代码都有“g++ .. -arch x86_64 -Xarch_x86_64 ..”时，32 位初始化如何潜入可执行文件？如果有必要的话，我在雪豹上。
----Begin-Edit----
经过这么多年，我很高兴地发现，当将 0 分配给指针时，标准不会强加值 0x00..00，但这不是本案中的问题。
#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);
}
如果我将上面的代码保存在“32_or_64.cpp”中，然后用“g++ -arch i386 32_or_64.cpp”编译它，我得到
Pointers in this executable use 4 bytes. A zero pointer in this executable is 0x0
如果我用“g++ -arch x86_64 32_or_64.cpp”编译它，我得到
Pointers in this executable use 8 bytes. A zero pointer in this executable is 0x0
如果你相信这个没有确定我的特定配置上的 0 不应该让我在 x86_64 中调试时看到精确的 0，请指出 出去。否则，辩论“null”是一场精彩的讨论，但在本线程中是无关紧要的。
----结束-编辑----
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----
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
更新：根据 π 的编辑，这个解释似乎是虚假的。但无论如何你可能会发现它很有趣。
在类 C 语言中，在源代码中写为
0的指针值只是指定 空指针。空指针是保证不指向任何对象的指针，它被定义为测试等于整数零，但它不需要具有与整数零相同的内部表示形式。空指针可以有多种表示形式，具体取决于体系结构，甚至取决于指针的类型。使用
0来表示“空指针”可能是一个不幸的约定； Steve Summit 的 C 编程语言常见问题解答 关于这个主题。我认为 hexa 的评论证明了理解这一约定的难度。问题在于需要区分三个概念：
0或NULL）。这是 C++ 标准，第 4.10 节：
这保证了您可以使用常量
0创建一个空指针，并通过与0比较来测试指针是否为空，但没有提及空值的机器表示指针。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
0in 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
0to 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:
0orNULL).Here's the C++ standard, section 4.10:
This guarantees that you can create a null pointer using the constant
0, and test whether a pointer is null by comparison with0, but says nothing about the machine representation of the null pointer.完全有可能您的
this指针没有指向正确的内存。如果您的程序表现出其他未定义的行为，那么这很可能只是随机垃圾内存。Perfectly possible that your
thispointer is not pointing to the correct memory. If your program exhibits other undefined behaviour, then it's perfectly possible that this is just random garbage memory.