Re: [PATCH 01/19] hw/core/loader.c: Fix type conflict of GLib function pointers

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Apr 16, 2025 at 11:00:37AM +0200, Paolo Bonzini wrote:
> Il mer 16 apr 2025, 10:29 Daniel P. Berrangé <berrange@redhat.com> ha
> scritto:
> 
> > > -    secs = g_list_sort(secs, sort_secs);
> > > +    secs = g_list_sort_with_data(secs, sort_secs, NULL);
> >
> > I don't see what the problem is with the original code.
> >
> > The commit message says we have a bad function cast, but the original
> > method decl is
> >
> >   GList *g_list_sort(GList*list, GCompareFunc compare_func);
> >
> > where the callback is
> >
> >    typedef gint (*GCompareFunc)(gconstpointer a, gconstpointer b);
> >
> > Our code complies with that GCompareFunc signature.
> >
> 
> The cast is inside glib; g_list_sort casts the function pointer and calls
> g_list_sort_with_data.

Sigh, the commit message should have said that, as it reads like the
problem is in QEMU code, not glib code.

> I suggested this solution to Kohei because it's easy to check that we're
> converting all users and not introducing new ones in the future (see
> poisoning in patch 10).

It is easy to check this /one/ example, but this pattern of bad casts
is typical in glib with likely many more examples, so avoidance in this
way does not feel like a sustainable long term strategy to me.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|