On Fri, May 29, 2009 at 7:17 PM, Julian Seward
<address@hidden> wrote:
+1 for that. Code that relies on malloc(0) doing any specific thing
is basically bad news when it comes to portability, robustness
and understandability. Better to have qemu_malloc(0) abort, put up with
a couple of days of the trunk aborting, until these uses are fixed.
I'd be surprised if there were many cases anyway.
I think there are two conflicting goals here:
- On one hand, people are suggesting to abort on malloc(0) because it is the sign of buggy code,
and would help spot it as soon as possible, before any damage is done.
- On the other hand, some people object that this assumption is sometimes wrong (e.g. with
arrays), where having malloc(0) returning NULL or anything else is totally appropriate.
Would it make sense to separate the two issues with something like the following:
- qemu_malloc(0) aborts and print a panic message
- qemu_calloc(count, itemsize) would return NULL for 'itemsize == 0', but would abort for 'count == 0'
- array-allocating/parsing code MUST use qemu_calloc() exclusively. And calloc() can also perform trivial
integer multiplication overflow checks too.
I would even suggest providing helper macros to make the programmer's intent even more clear
and less error-prone, as in:
#define QEMU_NEW(ptr) (ptr) = qemu_alloc(sizeof(*(ptr)))
#define QEMU_NEW_ARRAY(ptr,cnt) (ptr) = qemu_calloc((cnt),sizeof(*(ptr)))
#define QEMU_RENEW_ARRAY(ptr,cnt) (ptr) = qemu_realloc((ptr),(cnt),sizeof(*(ptr)))
#define QEMU_FREE_ARRAY(ptr) qemu_free(ptr)
(yes, qemu_realloc() would take 3 parameters).
Any direct use of malloc()/qemu_malloc() in source code would be suspicious and could
easily spotted to check it.
J