[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently

From: David Turner
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 23:12:32 +0200

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]