C语言深度解剖之——编译器的bug、for循环优化 2011-09-17 11:15:57 分类: C/C++ 《C语言深度解剖》的作者是个善于观察、思维缜密的人,在其著作中提出了许多值得思考的问题和细节,对于理解计算机系统原理具有很好的参考价值。这两天拜读了此书,今天跟大家一起探讨一下书中一个关于指针的有趣现象。如果你尚未读过原文,请先阅读原书对应的如下章节: ***********************************以下是原文************************************** 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。还有,这个小小的例子,你是否可以在多个编译器上测试测试呢? ************************************以上是原文************************************* 到此,相信你对作者所发现的有趣现象已经有所了解,现在就让我们通过实验+观察+分析,给这一现象一个合理的解释,一起来探讨一下,为什么会产生这种现象,这究竟是否是VC 6.0编译器存在的bug? 首先看作者给出的第一个例子: int *p = (int *)0x12ff7c; *p = NULL; p = NULL; 注意0x12ff7c的由来。作者是通过在变量p之前先定义变量i,然后在调试模式下观察到i的存储地址为0x12ff7c,接着将变量i的定义去掉,令p指向地址0x12ff7c对应的存储单元。不同的系统此值一般不同,这取决于操作系统为进程分配的内存空间(主要是堆栈区)的不同,请大家自行替换成合适的值。在我的计算机系统上调试时,对应的地址是0x0013ff7c。 接下来请大家测试如下代码,并对比四条printf语句的输出: int *p; printf("&p=%x,p=%x\n",&p,p); p = (int *)0x0013ff7c; printf("&p=%x,p=%x\n",&p,p); *p = NULL; printf("&p=%x,p=%x\n",&p,p); p = NULL; printf("&p=%x,p=%x\n",&p,p); 以下是输出结果: &p=13ff7c,p=cccccccc &p=13ff7c,p=13ff7c &p=13ff7c,p=0 &p=13ff7c,p=0 通过观察我们可以发现,变量p自定义以来,其存储位置(&p)并未改变,始终是0x13ff7c,随着对p或*p的操作发生变化的是p值。到此,大家已经隐约觉得这未必是编译器的bug了吧?继续分析!大家一定注意到了:&p恰好也是0x13ff7c,与p所指向的地址一致,这正是关键所在!语句p = (int *)0x0013ff7c使得p恰好指向其本身(这一点作者可能并未意识到,其实这很正常,分给该进程的堆栈空间起始位置固定,i原本在p之前紧挨着p定义,现将其去掉,自然原本应分给i的位置便分配给了变量p,而且int型和指针型都占4个字节的存储空间)。理解此问题的关键在于正确区别&p和p,&p表示系统为指针变量p分配的存储空间的位置,而变量窗口中显示的p值,代表为变量p所分配的存储单元中存储的内容,即它所指向的变量的地址。作者通过*p=NULL将p所指向的内容改为0,不就是将p值改成0了么? 由此可见,此现象并非编译器有bug,而是作者不慎混淆了&p和p的含义! 再看作者最后举的一个例子,我仍将相应的地址改为0x13ff7c: char *p = (char *)0x13ff7c; //0x13ff7c原是字符型变量ch对应的地址,现为变量p的首地址 *p = NULL; p = NULL; 作者正确观察到,执行完*p = NULL后,p的值并未变成0x00000000,而是变成了0x0013ff00,同时*p 的值变成了0。这究竟是怎么回事呢? 这里,指针p依然是指向自身,但此时的p为字符型指针,*p代表的仅为4字节变量p起始存储地址对应的字节,对于x86体系结构(little-endian)来说,是变量p内容的最低字节。执行完*p = NULL后,p内容的最低字节变为0(即*p变为0),即原来的最低字节0x7c被换成了0x00(注意此前p的内容为0x0013ff7c),于是p的内容变为0x0013ff00,即此时p已经指向新的地址0x0013ff00。 不习惯在debug模式下观察变量值的读者可以用下面的代码去观察输出结果: char *p; //此时已为变量p分配空间,但未初始化,其指向不定 printf("&p=%x,p=%x\n",&p,p); p = (char *)0x0013ff7c; printf("&p=%x,p=%x\n",&p,p); *p = NULL; //p的最低字节被改为0x00 printf("&p=%x,p=%x\n",&p,p); p = NULL; //p值(4字节)被置零 printf("&p=%x,p=%x\n",&p,p); 输出结果为: &p=13ff7c,p=cccccccc &p=13ff7c,p=13ff7c &p=13ff7c,p=13ff00 &p=13ff7c,p=0
通过上述实验与分析,我们可以发现,理论分析与实验结果完全吻合,编译器工作正常,并不存在什么所谓的bug。 |
|