Ages ago I worked with a system where malloc(0) incremented a counter and returned -1.
free(-1) decremented the counter.
This way you could check for leaks :p
replies(3):
free(-1) decremented the counter.
This way you could check for leaks :p
On most platforms an implementation could just return adjacent addresses from the top half of the address space. On 32-bit platforms it doesn't take long to run out of such address space however, and you don't want to waste the space for a bitmap allocator. I suppose you could just use a counter for each 64K region or something, so you can reuse it if the right number of elements has been freed ...
I know I've seen that somewhere, but may I ask what standard you're referring to?
If I recall correctly, this was an archaic stackless microcontroller. The heap support was mostly a marketing claim.
From C89, §7.10.3 "Memory management functions":
> If the size of the space requested is > zero, the behavior is implementation-defined; the value returned shall be either a null pointer or a > unique pointer.
The wording is different for C99 and POSIX, but I went back as far as possible (despite the poor source material; unlike later standards C89 is only accessible in scans and bad OCR, and also has catastrophic numbering differences). K&R C specifies nothing (it's often quite useless; people didn't actually write against K&R C but against the common subset of extensions of platforms they cared about), but its example implementation adds a block header without checking for 0 so it ends up doing the "unique non-NULL pointer" thing.