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:av1...@comtv.ru
