On 25.07.2011, at 12:59, Markus Armbruster wrote: > Avi Kivity <a...@redhat.com> writes: > >> On 07/25/2011 01:04 PM, Alexander Graf wrote: >>> On 25.07.2011, at 12:02, Avi Kivity wrote: >>> >>>> On 07/25/2011 12:56 PM, Alexander Graf wrote: >>>>>> >>>>>> That argument can be used to block any change. You'll get used to it >>>>>> in time. The question is, is the new interface better or not. >>>>> >>>>> I agree that it keeps you from accidently malloc'ing a struct of pointer >>>>> size. But couldn't we also just add this to checkpatch.pl? >>>> >>>> Better APIs trump better patch review. >>> >>> Only if you enforce them. The only sensible thing for QEMU_NEW (despite the >>> general rule of upper case macros, I'd actually prefer this one to be lower >>> case though since it's so often used) would be to remove qemu_malloc, >>> declare malloc() as unusable and convert all users of qemu_malloc() to >>> qemu_new(). >> >> Some qemu_mallocs() will remain (allocating a byte array or something >> variable sized). > > Byte array: add the obvious type-safe allocator for a variable-sized > array T[N], then use it with unsigned char for T. > > In fact, I find QEMU_NEW() pretty pointless without a buddy for arrays.
#define QEMU_NEW_MULTI(type, len) ((type *)(qemu_mallocz(sizeof(type) * len))) char *arr = QEMU_NEW_MULTI(char, 1024); > Still not covered: allocating a struct with a variable-size array as > final member. I guess a solution for that can be found if we care > enough. Yeah, but at the end of the day I'd assume most of us know C and can just open code this all, no? Alex
