2012-6-27整理
cswuyg
前几天遇到过一种奇葩的代码，用0xFEEEFEEE来判断是否是悬垂指针，这种必须反对，太冒险了。
另外填充值到底是什么呢？发觉要全面彻底分析，不是那么简单，最后只是把网络上的一些资料拿到这里，作为记录。
一、Release下，用OllyDbg查看
1、申请了50个字节的空间。可以看到被初始化为0xBAADF00D。
2、把申请的内存释放之后，释放之后内存初始化为0xFEEEFEEE。
二、debug下用VS2005查看
1、申请了50个字节的空间。可以看到被初始化为0xcdcdcdcd
2、把申请的内存释放之后，初始化为0xFEEEFEEE
三、总结
按照网络上某篇文章的说法：“CRT通常会调用HeapFree()函数将本内存块归还给win32堆, win32堆会将本内存块填充为0xFEEEFEEE。”也就是说，debug、release下都会出现0xFEEEFEEE，因为它们都会调用HeapFree()函数。
“HeapAlloc()返回的内存总是被一4字节对齐初始化为0xBAADF00D”，也就是说release下的内存，直接就是HeapAlloc操作的结果，外界不再做附加操作。而debug下，则会再初始化一次，变成0xCDCDCDCD。
另外，需要注意，这些信息只是用来了解，不要在程序里利用它们，这是编译器相关的东西。
下边附上在网络上找到的资料，我尝试去验证，但发觉事情没那么简单，即便是在编译器干最少内存附加处理的Release模式下，仍然发现内存空间的申请比之前测试过的GCC复杂了许多，申请8个byte的空间，却看到内存里有40个byte的值发生了变化，最后发觉似乎8byte的空间占据了32byte的内存，没有大把时间花在这里去猜测附加空间以及它的填充值的用途，就这样吧，这些属于比较偏的知识。堆空间的分配细节，相比之下GCC可就简单多了，可以用code::block测试它们的这些区别。
附上网络上的非常详细的解释：
* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory
参考资料：网络上非常多，就不列举了。
