Re: malloc(0) behaviour

[Rob Landley <rob@landley.net>]

On 01/14/2013 06:24:42 PM, Rich Felker wrote:
> > Not indicating that the allocation failed and triggering an assert()
> > when there isn't actually a problem with a legitimately zero length
> > array that had nothing in it? (Both times I debugged why LFS stuff
> > was failing that's what it turned out to be, but I didn't spend too
> > much time on it before just switching the uClibc option on to
> > support it.)
> 
> While in some cases it would be nice to get a fault, you don't usually
> get a fault when trying to access past the end of a length-1 array, so
> why should you expect one when trying to access past the end of a
> "length-0 array"?

Nobody accessed it. They were doing something handwavingly like:

   if (!(array=malloc(sizeof(struct blah)*len))) die();
   for (i=0; i<len; i++) blah();

Which works just fine for len=0 because the for loop doesn't do  
anything... assuming malloc doesn't return 0 and trigger the allocation  
failure check.

(But again, this was ~5 years ago. Haven't tried switching it off  
since.)

> > >except to support buggy and lazy programming.
> >
> > You're defining "lazy" here a "not adding a special case in the
> > caller for every use of malloc()". That's certainly a point of view,
> > but I'm not sure that's the word you want to use for it. "Not
> > sufficiently defensive programming" maybe?
> 
> Well, doing nothing to account for the fact that malloc(0) "failing"
> might not indicate a problematic OOM condition is "lazy" in my book.

Maybe, but it means they're special casing 0, when otherwise it just  
works. (At least on eglibc, and getting people to care about  
portability off glibc remains a thing.)

My point was that requiring them to special case this is not  
necessarily an improvement.

Rob