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.
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.
Being tasked to implement a specification typically means having to pass extensive conformance tests and having to answer for instances of noncompliance. You soon learn to follow the spec to the letter, to the best of your abilities, unless you can make a strong case to your management for each specific deviation.
The C99 standard[1] seems to have worded it more precisely:
If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.
[1]: https://rgambord.github.io/c99-doc/sections/7/20/3/index.htm...
It returns multiple types of null pointer