It's common to use fixed magic numbers for things like allocation headers/footers to detect write-clobbering corruption but you can actually do one better with incrementally updatable checksums at a very manageable cost. An intentional field write removes the checksum contribution corresponding to its old value before writing the new value and then it adds in the checksum contribution corresponding to the new value. There's an obvious concurrency issue here, so reason and apply accordingly. 

 @04e720cb interesting idea, but I don't often see intentional field updates being instrumented, the way allocators are. E.g. my malloc leak tracer uses a magic number to identify live allocs, and erases the number on frees. Besides alloc and free, there's no other interaction with the library. A fixed magic number would be the only thing usable for boundary checking. https://github.com/hyc/mleak