Some bits on malloc(0) in C being allowed to return NULL
utcc.utoronto.ca
Some bits on malloc(0) in C being allowed to return NULL
1–10 of 84 posts
Re: Some bits on malloc(0) in C being allowed to return NULL
#2Ages 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
Re: Some bits on malloc(0) in C being allowed to return NULL
#3Ages 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
Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`.
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 ...
Re: Some bits on malloc(0) in C being allowed to return NULL
#4Ages 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
I might be missing something, but how does this help in checking for leaks? I mean, I guess you could use it to check for leaks specifically of 0-sized allocations, but wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all?
Re: Some bits on malloc(0) in C being allowed to return NULL
#5Why should it be allowed to return a valid pointers anyways? Surely it should always return NULL?
Re: Some bits on malloc(0) in C being allowed to return NULL
#6Why should it be allowed to return a valid pointers anyways? Surely it should always return NULL?
For instance, because you are prohibited from passing NULL to e.g. memcpy and lots of other library functions from memory.h/string.h, even when you explicitly specify a size of 0.
Another use was to use it to mint unique cookies/addresses, but malloc(1) works for this just as well.
Re: Some bits on malloc(0) in C being allowed to return NULL
#7Not the best choice to begin the title with "some bits" in this context. My mind was trying to understand this sentence in a completely different way...
Re: Some bits on malloc(0) in C being allowed to return NULL
#8Why should it be allowed to return a valid pointers anyways? Surely it should always return NULL?
It's not a valid pointer because you can't use the indirection operator on it. Returning a value other than NULL makes sense because an allocation of size zero is still an allocation.
Additionally the actual amount of memory malloc allocates is implementation-defined so long as it is not less than the amount requested, but accessing this extra memory is undefined behavior since processes don't know if it exists or not. a non-NULL return could be interpreted as malloc(0) allocating more than zero bytes.
Some implementations don't actually perform the allocation until theres a pagefault from the process writing to or reading from that memory so in that sense a non-NULL return is valid too.
I'd argue that malloc(0)==NULL makes less sense because there's no distinction between failure and success.
The only real problem is specifying two alternate behaviors and declaring them both to be equally valid.
Re: Some bits on malloc(0) in C being allowed to return NULL
#9Ages 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
I might be missing something, but how does this help in checking for leaks? I mean, I guess you could use it to check for leaks specifically of 0-sized allocations, but wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all?
At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free().
If malloc() had returned a real pointer, you'd have to free that too.
> wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all?
Better: takes less memory Worse: blinds you to this portability issue.
Re: Some bits on malloc(0) in C being allowed to return NULL
#10Ages 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
Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. 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 somethin…
Noncompliant, but what could this reasonably impact?