Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> On 12/07/2009 05:50 PM, Anthony Liguori wrote:
>>
>> While it's always fun to argue about standards interpretation, I 
>> wanted to capture some action items from the discussion that I think 
>> there is agreement about.  Since I want to make changes for 0.12, I 
>> think it would be best to try and settle these now so we can do this 
>> before -rc2.
>>
>> For 0.12.0-rc2:
>>
>> I will send out a patch tonight or tomorrow changing qemu_malloc() to 
>> return malloc(1) when size=0 only for production builds (via 
>> --enable-zero-mallocs).  Development trees will maintain their 
>> current behavior.
>>
>
> Since active development is ceasing on 0.12, I'd suggest not having 
> separate behaviour for devel and production.  Do we want patches for 
> n==0 array allocations at this time?

Covering every qemu_malloc instance this close to the GA is too risky.  
I agree that having separate behavior is less than ideal but I think 
it's the only sane way forward.

> I'd really like to see Markus' patch applied.

For 0.12, that doesn't seem like a possibility.

>> For 0.13:
>>
>> Someone (Marcus?) will introduce four new allocation functions.
>>
>> type *qemu_new(type, n_types);
>> type *qemu_new0(type, n_types);
>>
>> type *qemu_renew(type, mem, n_types);
>> type *qemu_renew0(type, mem, n_types);
>>
>
> I'd like to see separate functions for arrays and single objects, to 
> avoid ", 1)" everywhere.
>
>   qemu_new()
>   qemu_new0()
>
>   qemu_new_array()
>   qemu_new_array0()
>   qemu_renew_array()
>   qemu_renew_array0()

Like I said, I'm not tied to naming.  I'll defer this to whoever 
contributes the patch and signs up for the conversion work.

> In addition, Markus' patch should be applied to master to avoid 
> regressions while the code is converted.

Let's separate that discussion as it's an independent consideration.

Regards,

Anthony Liguori