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

[Blue Swirl]

On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivity <address@hidden> wrote:
> On 08/18/2011 09:54 PM, Peter Maydell wrote:
>>
>> On 18 August 2011 18:48, Avi Kivity<address@hidden>  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.

Also plain malloc() and friends, except in tracing back end for obvious reasons.

>> (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.
>
>