[libvirt PATCH v2 1/3] docs: Drop glib-adoption.rst

Daniel P. Berrangé berrange at redhat.com
Mon May 11 12:42:54 UTC 2020


On Mon, May 11, 2020 at 02:35:33PM +0200, Andrea Bolognani wrote:
> On Mon, 2020-05-11 at 14:24 +0200, Ján Tomko wrote:
> > On a Thursday in 2020, Andrea Bolognani wrote:
> > > -The following is a list of libvirt APIs that should no longer be
> > > -used in new code, and their suggested GLib replacements:
> > > -
> > > -``VIR_ALLOC``, ``VIR_REALLOC``, ``VIR_RESIZE_N``, ``VIR_EXPAND_N``, ``VIR_SHRINK_N``, ``VIR_FREE``, ``VIR_APPEND_ELEMENT``, ``VIR_INSERT_ELEMENT``, ``VIR_DELETE_ELEMENT``
> > > -   Prefer the GLib APIs ``g_new0``/``g_renew``/ ``g_free`` in most
> > > -   cases. There should rarely be a need to use
> > > -   ``g_malloc``/``g_realloc``. Instead of using plain C arrays, it
> > 
> > This is the only place where the preferred GLib functions are
> > documented, I think deleting it is premature.

It is also documented in the viralloc.h header

> The patch has already been merged.
> 
> I think regular contributors have become used to the GLib APIs by
> now, and drive-by contributors were probably not familiar with the
> libvirt APIs in the first place, so this list was of no use to them.

We're still at a 10:1 ratio of VIR_ALLOC:g_new0 which suprised me a
bit.

We were quite succesful with our big push to convert other areas of
code to GLib APIs. eg the ATTRIBUTE_*.  Admittedly these were simpler
cases, but we could benefit from being a bit more aggressive in
eliminated VIR_ALLOC related APIs at least.


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 :|




More information about the libvir-list mailing list