Re: [PATCH] Introduce QEMU_NEW()

Alexander Graf
2011-07-25T10:19:54Z

On 25.07.2011, at 12:09, Avi Kivity wrote:

> 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).

Right. But then we really do need a check in checkpatch.pl to see if someone's using qemu_new for simple structs.

> I agree qemu_new() will be nicer, but that will have to wait until Blue is several light-days away from Earth.

Blue, any disagreement on adding qemu_new() as a macro? Something used that often in upper case would seriously disturb the reading flow :)

Alex