It uses calloc() which then uses... the system library's malloc(). I'm not sure what utility this has --- all it does is add some headers and footers to the allocated block in an attempt to catch overflow writes, but practically all existing malloc()s do that already.
I wondered the same thing! If the goal is to add "debuggability", then there are other options out there too -- dmalloc and electric fence, to name just two.
I went to the repo fully expecting to see a call to brk() somewhere in the code.
It disallows free(NULL) which the standard allows, so it's not a drop-in replacement. Hard to see the added value although allocators can be good for learning.
Maybe as a debugging cover for memory (but then you'd expect functionality for heap checking, block tracking and leak detection, etc). Forbidding a null pointer on free is a breaking change and a little naive. It's not terribly useful.
The author of this could have picked a better value to fill in the guard area. For the x86 architecture, 0xCC is a good choice. It's an unusual negative value, a largish unsigned value, most likely an invalid address (if dereferenced as a pointer) and if executed, is the INT 3 breakpoint instruction. Other architectures would require different values, but at least pick one that has a good chance of blowing something up if used.
8 comments
[ 3.5 ms ] story [ 39.3 ms ] threadI went to the repo fully expecting to see a call to brk() somewhere in the code.
Will