生死疆界（下）--- 在new与delete之间
作者：土豆
上回《生死疆界(上)》说到:
咱们对着微软在背后做的手脚深感困惑，于是备好车马粮草，一路追杀进去，最后走进了死胡同，剩下的最后希望就是在这里摸摸，那里敲敲，看有没有暗藏机关。
这正是：探源码身陷绝境，求解脱心系参数。
还记得我们在delete p;前设的断点吗？好，让我们重新开始调试，按F5，从控制台输入"abcd"，然后到这条语句前停止了，查看变量p的值，是0x00342c40，那好，打开vc监视内存的窗口memory，我们查看这个地址的值：
此后的内存情况不再用图片显示。只用红色标志的内存表示发生了变化的内存
看到了吗？你的宝贝"abcd"乖乖地躺在内存中，其后跟了一个0x00，那表示''\0''，字符串结束标志。一切都很正常，到底哪里出错了？难道是delete
p用错了，而应该用delete[] p？try it,你会发现依然有相同的错误。
从这段内存中仍然看不出问题，仿佛一切风平浪静，其实是我们来晚了，在delete p前，内存早已经发生了翻天覆地的变化。 再一次重新进入程序，这次我们从一开始就监视内存。
00342C40 EE FE EE FE EE FE EE 铪铪铪.
00342C47 FE EE FE EE FE EE FE .
这是char *p = new char,执行前的内存。下面是执行后的:
00342C40 CD FD FD FD FD F0 AD 妄.
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...
看不出什么问题，再往下执行吧：(cinp, 这次我们输入ab）
00342C40 61 62 00 FD FD F0 AD ab.瓠
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...
ab正确地放进了内存中，而且你可以看到cin还体贴地在ab后为你放了一个''\0''
还是没有什么问题？再往下走就是cout<<p了，它不会改动内存，再往下就到了delete p，到那时一切都晚了。 没错，就是这一步，静静的内存中早已经翻江倒海。
还记得static int __cdecl CheckBytes(unsigned char * pb, unsigned char bCheck,
size_t nSize)中的bCheck, nSize吗？ 如果当初你也监视变量的话，会发现bCheck = 253, nSize = 4。这就是这个内存侦测机制的命门。小时候喜欢看武打片，有一部叫做〈鹰爪铁布衫〉的，当时令我如痴如醉啊，看过的人一定还记得最后杀那老头的时候是先在他天灵上一拍，接着再在裤裆上捏一把，呵呵，bCheck就是天灵，nSize就是裤裆。
把253转换为16进制，是什么，没错，是FD。呵呵，别忙往下看，想一想，你找到真相了吗？ 再看一眼char *p = new char执行后的内存，你发现了什么？p指向0x00342c40那个字节的值为CD，这是属于你的内存，看看后边跟的是什么，不多不少，恰恰是4个FD，恰恰是nSize个bCheck！
这个侦测内存非法访问的机制现在已经被我们开膛破肚了。微软在你申请的空间后加上四个FD，如果你访问了你非法访问内存，那么这些内存的内容将被改变(有一个问题我没有解决，我不知道FD代表什么，望知道的兄弟教我)，在delete时，将检查由new产生的''\0''结束符后是否有连续四个字节都是FD，如果有证明没有发生非法内存访问，如果没有，那就该让_RPT3老兄出马了。
对于
char *p = new char;
cinp;
cout<<p;
delete p;
这段代码，如果只输入一个字符a，cinp执行后的内存为
00342C40 61 00 FD
FD FD F0 AD a..
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...
虽然你只用了你申请的内存，但是cin为了讨好你给你加那个''\0''，覆盖了一个FD，这样，delete时照样报错，如果你这样做
char *p = new char[2];
那么cinp后内存为
00342C40 61 00 FD
FD FD FD AD a..
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...
那么程序将不会报错。 四个FD就是内存的生死疆界，超过这个疆界，呵呵，听见远方传来的崩溃的声音了吗？ 到此，一切真相大白，山高月小，水落石出！
（尾声：以上所有内容皆来自笔者独立分析，其中难免有错，更甚者，也许我大错特错，压根就不是这样的机制。如果你发现其中有不正确的地方，请指出，谢谢，在下感激不尽）。
