Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()

[Markus Armbruster]

Avi Kivity <address@hidden> 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.

[...]