qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
Date: Fri, 19 Aug 2011 08:22:54 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0

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.


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]