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

[Anthony Liguori]

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