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

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

 



On 25.07.2011, at 12:59, Markus Armbruster wrote:

> Avi Kivity <avi@xxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux