For the confused, 43605 in decimal is 0xaa55 in hexadecimal.

That should be the default behaviour, perhaps with random values too.

It’s easier when it is a specified value. Easier to see in a debugger and to diagnose. Sure, it can occasionally be interpreted as meaning something, but so can random gibberish. As long as everything is overwritten, there is no privacy issue.

> Sure, it can occasionally be interpreted as meaning something, but so can random gibberish.

Some gibberish is better than others. For instance, on x86 (64-bit, 32-bit, or even 16-bit), filling with the 0xcc byte means that, if executed as code, it will trap (0xcc is the single-byte INT3 "single-step breakpoint" instruction). And for most Unix-style operating systems, which put the kernel in the high half of the address space, the filler bytes should have the high bit set, so that treating them as pointers will trap (the pointer will have its high bit set, pointing to kernel memory, which user space is forbidden from accessing).

Having a different pre-defined value for allocation vs deallocation scribble is nice because you can then tell if the error happened pre-initialization or post-free. $AA and $55 also weren't chosen by accident one assumes, $AA is 1010_1010 and $55 is 0101_0101. Consistent values help with reproduction.

The Linux setup where you can choose your own scribbles seems to meet your needs no?

> For instance, on x86 (64-bit, 32-bit, or even 16-bit), filling with the 0xcc byte means that, if executed as code, it will trap (0xcc is the single-byte INT3 "single-step breakpoint" instruction).

Trying to execute off the heap is going to trap anyways.

Or just use valgrind.

Or just use a memory safer programming langage.

If your use case fits into capabilities of such language, and you have the necessary libraries, and bindings, etc., then why not?

It’s slower.