On 08/18/2011 09:54 PM, Peter Maydell wrote:
On 18 August 2011 18:48, Avi Kivity<a...@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.
