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
參考資料：網絡上非常多，就不列舉了。