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. 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. [...]
