Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends

[Anthony Liguori]

Avi Kivity wrote:
> On 12/04/2009 06:49 PM, Anthony Liguori wrote:
> > I still believe that it is poor practice to pass size==0 to 
> > *malloc().  I think actively discouraging this in qemu is a good 
> > thing because it's a broken idiom.
>
> Why?  Unless we have a separate array allocator (like C++'s new and 
> new[]), we need to support zero-element arrays without pushing the 
> burden to callers (in the same way that for () supports zero iteration 
> loops without a separate if ()).

If you call malloc(size=0), then it's impossible to differentiate 
between a failed malloc return and a valid result on certain platform 
(like AIX).

So the only correct way would be to write:

array = malloc(size);
if (array == NULL && size != 0) {
   return -ENOMEM;
}

If you were writing portable code.  But that's not what people write.  
You can argue that qemu_malloc() can have any semantics we want and 
while that's true, it doesn't change my above statement.  I think the 
main argument for this behavior in qemu is that people are used to using 
this idiom with malloc() but it's a non-portable practice.

If qemu_malloc() didn't carry the name "malloc()" then semantics with 
size=0 would be a different discussion.  But so far, all qemu_* 
functions tend to behave almost exactly like their C counterparts.  
Relying on the result of size=0 with malloc() is broken.

Regards,

Anthony Liguori