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.

Will

Seems like the header and footer are the same too. Odd choice.

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.

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.

This is implemented in terms of calloc()/free(). Is this a joke? Or some kind of post-modern art? Genuinely curious, the use cases aren't clear.

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.

phkmalloc is a real (but single-threaded) allocator and less than 1200 lines: https://svnweb.freebsd.org/base/stable/4/lib/libc/stdlib/mal...