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
