《C语言深度剖析》电子版4.1.5小节的错误

最近在朋友的推荐下读了《C语言深度剖析》（电子版），虽然这本书讲的知识点在《C程序设计语言》《C专家编程》《C的陷阱和缺陷》这三本书中都有，但是作者把这些知识点提炼到100多页的书中，而且讲得层层递进，逻辑性很好，确实让人钦佩！感谢作者免费在网上共享此书的电子版。

 

在阅读的过程中发现4.1.5小节存在错误，在网上搜了一下，作者好像没有在网上放电子版的勘误表。把这个问题放在这里，希望对只看此书电子版的初学者有帮助。

 

这个问题只在电子版中存在，已经和作者陈正冲兄联系过，问题在实体书上已经修正了。

原文如下：

===================================================================================

4.1.5，编译器的bug？

另外一个有意思的现象，在Visual C++ 6.0调试如下代码的时候却又发现一个古怪的问题：

int *p = (int *)0x12ff7c;

*p = NULL;

p = NULL;

在执行完第二条代码之后，发现p 的值变为0x00000000 了。按照我么上一节的解释，应该p的值不变，只是p 指向的内存被赋值为0。难道我们讲错了吗？别急，再试试如下代码：

int i = 10;

int *p = (int *)0x12ff7c;

*p = NULL;

p = NULL;

通过调试，发现这样子的话，p 的值没有变，而p 指向的内存的值变为0 了。这与我们前面讲解的完全一致。当然这里的i 的地址刚好是0x12ff7c，但这并不能改变“*p = NULL;”这行代码的功能。

为了再次测试这个问题，我又调试了如下代码：

int i = 10;

int j = 100;

int *p = (int *)0x12ff78;

*p = NULL;

p = NULL;

这里0x12ff78 刚好就是变量j的地址。这样的话一切正常，但是如果把“int j = 100;”这行代码删除的话，又出现上述的问题了。测试到这里我还是不甘心，编译器怎么能犯这种低级错误呢？于是又接着进行了如下测试：

unsigned int i = 10;

//unsigned int j = 100;

unsigned int *p = (unsigned int *)0x12ff78;

*p = NULL;

p = NULL;

得到的结果与上面完全一样。当然，我还是没有死心，又进行了如下测试：

char ch = 10;

char *p = (char *)0x12ff7c;

*p = NULL;

p = NULL;

这样子的话，完全正常。但当我删除掉第一行代码后再测试，这里的p 的值并未变成0x00000000，而是变成了0x0012ff00，同时*p 的值变成了0。这又是怎么回事呢？初学者是否认为这是编译器“良心发现”，把*p 的值改写为0 了。

如果你真这么认为，那就大错特错了。这里的*p 还是地址0x12ff7c 上的内容吗？显然不是，而是地址0x0012ff00 上的内容。至于0x12ff7c 为什么变成0x0012ff00，则是因为编译器认为这是把NULL 赋值给char 类型的内存，所以只是把指针变量p 的低地址上的一个字节赋值为0。至于为什么是低地址，请参看前面讲解过大小端模式相关内容。

测试到这里，已经基本可以肯定这是Visual C++ 6.0 的一个bug。所以平时一定不要迷信某个编译器，要相信自己的判断。当然，后面还会提到一个我认为的Visual C++ 6.0 的一个bug。还有，这个小小的例子，你是否可以在多个编译器上测试测试呢？

======================================================================

 

分析

 

先不说别的，只要想一想：如果一个编译器对“*p = NULL;p = NULL;”这样的语句处理都出现错误的话，那这个编译器是无法正常使用的，因为这些语句太常见！更何况是VC 6.0这样一个广泛使用的编译器？所以这不太可能是VC的bug。

 

再看测试程序

int *p = (int *)0x12ff7c;

*p = NULL;

p = NULL;

这个变量地址是怎么来得呢？在书的4.1.4小节说了：

“……其实这很简单，我们可以先定义一个变量i，比如：

int i = 0;

变量i所处的内存肯定是可以被访问的。然后在编译器的watch 窗口上观察&i 的值不就知道其内存地址了么？这里我得到的地址是0x12ff7c，仅此而已（不同的编译器可能每次给变量i分配的内存地址不一样，而刚好Visual C++ 6.0 每次都一样）。……”

 

通过这段话可以确定0x12ff7c是在栈上的地址，我们知道临时变量是分配在栈中的，在上面的代码中p是临时变量，int *p = (int *)0x12ff7c;这句话的结果如下：

也就是说p分配在了栈中，地址是0x12ff7c，并且p所指向的地址也是0x12ff7c，p是一个指向自身的指针，相当于：

int *p；

p = （int *）&p；

此时无论是操作p和*p的结果都是一样的：

*p = NULL; //p指向的内容变为0，也就是地址0x12ff7c里的内容变为0

p = NULL;//p指向0，也就是p所在地址0x12ff7c里存储0

 

后面出问题的测试程序：

unsigned int i = 10;

//unsigned int j = 100;

unsigned int *p = (unsigned int *)0x12ff78;

*p = NULL;

p = NULL;

和上面一样还是指向自身的指针：

 

 

char *p = (char *)0x12ff7c;

*p = NULL;

p = NULL;

p为char类型指针，结合x86的little endian，存储结构如下：

 

*p = NULL;//*p只是指向了0x12ff7c开始的第一个字节7c，7c被替换为00

 和作者所说的结果是一致的。

 

结论：这是一个“指向自身的指针”的正常行为，不是编译器的bug。

 

多说两句：

栈是由操作系统管理的（没有操作系统的话，编译器也会解决这个问题），滥用指向栈的内容的指针，很可能会出现一些意想不到的问题，比如，几乎所有的C语言书籍都会提到函数返回指向栈的指针这一“经典错误”。