|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |