Some bits on malloc(0) in C being allowed to return NULL

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.

> but wouldn’t it be better just to return NULL and guarantee that 0-sized allocations never use any memory at all?

This works if you are only interested in the overall memory balance. However, if you want to make sure that all malloc() calls are matched by a free() call, you need to distinguish between NULL and a successfull zero-sized allocation, otherwise you run into troubles when you call free on an "actual" NULL pointer (which the standard defines as a no-op).

> At the end of main, if the count wasn't balanced, then you knew you had a mismatch between malloc()/free().

A mismatch between malloc(0) and free(-1).

You’d know nothing about calls to malloc with non-zero sizes.

Yeah, exactly, that’s my point. How many programs have memory leaks limited to (or even just materially affected by) 0-sized allocations? I’d have to imagine its a very small minority.

Those are identifiable by the end state of the heap not being empty.

They're uncommon for sure. In the past they've been an issue for me on constrained systems where they can frag the heap as badly as any other long lived allocation.