On Fri, May 29, 2009 at 7:17 PM, Julian Seward <jseward@acm.org> 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
>
>
>