qemu-devel
[Top][All Lists]
Advanced

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

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


From: malc
Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW()
Date: Mon, 25 Jul 2011 14:46:21 +0400 (MSD)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Mon, 25 Jul 2011, Alexander Graf wrote:

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

So do not use it then, macros should be uppercase.

-- 
mailto:address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]