Re: malloc(0) behaviour

[Rich Felker <dalias@aerifal.cx>]

On Tue, Jan 15, 2013 at 12:06:18PM +0100, Szabolcs Nagy wrote:
> * Igmar Palsenberg <igmar@palsenberg.com> [2013-01-15 09:31:24 +0100]:
> > > 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
> > > 
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm
> > > http://austingroupbugs.net/view.php?id=400
> > > http://sourceware.org/bugzilla/show_bug.cgi?id=12547
> > 
> > While the above is clear to me, returning a pointer that can't hold anything just seems wrong to me.
> 
> i don't think we have too many options here,
> the standards and historical practices has
> various inconsistencies and musl has the least
> broken one
> 
> but we can do a theoretical discussion about
> the merits of malloc(0)!=0:
> 
> i'm surprised that it "seems wrong" to you,
> you can access the amount of bytes you requested
> through the returned pointer p, evaluating
> p+size is valid, p is suitably aligned for all
> objects and it can be freed.
> these assumptions are broken if malloc(0)==0
> 
> if the standard made malloc(0) work in ansi c
> then it would save some branch logic and would
> made the world a safer place
> (because in a fair amount of code that gets
> array length from external source no special
> casing would be needed for length==0)

In fairness, there's hardly any difference between the work involved
in:

    if (size < LIMIT)

and

    if (size-1 < LIMIT-1)

The latter catches 0 and treats it as invalid.

> > I'll wrap malloc() to include an abort in my case :)
> 
> but don't do that in library code that may be
> used in a long running process: allocation failures
> should be reported to let the caller handle it

I think he meant malloc(0) would abort to indicate that, in the rules
of his project, malloc(0) is a programming error. This is not such a
bad idea..

Rich