In any case, the probability of detecting a buffer overrun using a fixed magic value is already 1 - 2**-32. Isn't that enough for you?

The problem is that in real life the data written by overruns is rarely ever random.

The problem I saw yesterday was that the over run occurred at both the source and destination of a memcpy().

Running it under the debugger with a debug malloc() in force and what happened is that as both source and destination fields were equal sized and equally aligned, the debug telltale signature that followed both chunks was identical; so the over run copied the telltale following the source buffer exactly on top of the telltale following the destination buffer.

So the heap check didn't detect the overrun!

But data following the telltale following the source also got copied over the data following the telltale at the destination; which showed up later when an entirely unrelated variable contained an impossibly high value and crashed the program. And I spent a long time looking in the wrong place.

Hence, I reasoned that if the telltales were all different the heap check would have found the error earlier and pointed me at the real culprit.

But, how could you make the telltales all different and still know what to look for? And that's when the offset idea hit me.

Even for 64-bit addresses, it is fast to derive a 32-bit offset from the nearest preceding 4GB boundary.

And the only way the same problem could occur is if the source and destination pointers were exactly 4GB apart; which is considerably less likely than the 16/32/64-byte granularities often used by standard mallocs.