On Mon, Jun 08, 2020 at 09:06:17 +0100, Alex Bennée wrote: > Emilio G. Cota <c...@braap.org> writes: > > I'd rather use asprintf(3) and strdup(3) here, so that plugins don't > > have to worry about glib, and on the QEMU side we don't have to worry > > about plugins calling free() instead of g_free(). > > AFAIK you can actually mix free/g_free because g_free is just a NULL > checking wrapper around free.
I was just going with the documentation, but you're right: https://github.com/GNOME/glib/blob/mainline/glib/gmem.c#L196 > void > g_free (gpointer mem) > { > free (mem); > TRACE(GLIB_MEM_FREE((void*) mem)); > } The NULL-pointer check is done by free(3), though. > However ideally I'd be passing a > non-freeable const char to the plugin but I didn't want to expose > pointers deep inside of QEMU's guts although maybe I'm just being > paranoid there given you can easily gdb the combined operation anyway. > > Perhaps there is a need for a separate memory region where we can store > copies of strings we have made for the plugins? I agree with the idea of not exposing internal pointers to plugins (e.g. we don't pass a CPUState *, only an opaque handle) so I'm OK with returning a dup'ed string here. (snip) > That said in another > thread Peter was uncomfortable about exposing this piece of information > to plugins. Maybe we should only expose something based on the optional > -device foo,id=bar parameter? I have no opinion on whether exposing this is a good idea. If it turns out that it is, please have my Reviewed-by: Emilio G. Cota <c...@braap.org> Thanks, Emilio
