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).
I agree qemu_new() will be nicer, but that will have to wait until Blue
is several light-days away from Earth.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
