Re: malloc(0) behaviour

[Rich Felker <dalias@aerifal.cx>]

On Mon, Jan 14, 2013 at 05:22:16PM -0500, Strake wrote:
> On 14/01/2013, Rich Felker <dalias@aerifal.cx> wrote:
> > Yes, there are many good reasons. The most obvious (but stupid) one is
> > that a huge number of programs will "replace" malloc with one where
> > malloc(0) returns something other than a null pointer if the system's
> > malloc(0) returns null, and this adds both bloat and risk of
> > bugs/breakage from the replacement. But there are other much more
> > fundamental reasons too. Basically they all come down to interactions
> > between the requirements of malloc and realloc, and the fact that
> > returning a null pointer from realloc means failure (and thus that the
> > original object was not freed).
> 
> Another: Null means allocation failure. As malloc ought to never fail
> to find zero bytes free, it thus makes sense to return a non-null
> pointer.

Yes. In any case, I don't see why a correct program would care what
malloc(0) returns, since passing 0 to malloc just makes it harder to
write a correct program. Normally after calling malloc, you check the
return value, and handle it as an error if the return value is a null
pointer. But if your program might pass 0 to malloc, you have to also
consider the possibility that the null pointer was returned not as an
error but as the "success" result for malloc(0). This greatly
complicates your error handling; now you have to either clear errno
first and check whether it's set after the call to malloc to determine
whether allocation failed, or check for size==0 in the failure case
and treat that specially as a sort of success.

Things get even worse if you use realloc(p,0), especially if you want
to support non-conforming implementations like glibc...

Rich