Aargh, I was confused, I meant: - qemu_calloc(count, itemsize) would abort for 'itemsize == 0', but return NULL for 'count == 0' sorry about that.. On Fri, May 29, 2009 at 11:12 PM, David Turner wrote: > > > On Fri, May 29, 2009 at 7:17 PM, Julian Seward 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 >> >> >> >