Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family

[Avi Kivity <avi@redhat.com>]

On 08/18/2011 09:54 PM, Peter Maydell wrote:
> On 18 August 2011 18:48, Avi Kivity<avi@redhat.com>  wrote:
> >  +static GMemVTable gmemvtable = {
> >  +    .malloc = qemu_malloc,
> >  +    .realloc = qemu_realloc,
> >  +    .free = qemu_free,
> >  +};
> >  +
> >  +/**
> >  + * qemu_malloc_init: initialize memory management
> >  + */
> >  +void qemu_malloc_init(void)
> >  +{
> >  +    g_mem_set_vtable(&gmemvtable);
> >  +}
>
> Does this mean you can now safely allocate with g_malloc
> and free with qemu_free, or is mixing the two APIs like that
> still a no-no ?

You can, but I'd forbid it.  Mixing layers can only lead to tears later on.

Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to 
reduce confusion.

>
> (I'm thinking about a situation where you might use a glib utility
> function that returned g_malloc'd memory and want to pass that back
> to your caller without having to either copy to qemu_malloc'd memory
> or require your caller to care about the distinction.)
>

Changing ownership of memory is rare, I hope.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.