On Mon, Sep 30, 2019 at 02:21:46PM +0200, Peter Krempa wrote: > On Mon, Sep 30, 2019 at 13:19:41 +0100, Daniel Berrange wrote: > > On Mon, Sep 30, 2019 at 02:03:53PM +0200, Peter Krempa wrote: > > > On Mon, Sep 30, 2019 at 13:56:06 +0200, Pavel Hrdina wrote: > > > > On Mon, Sep 30, 2019 at 12:45:56PM +0100, Daniel P. Berrangé wrote: > > > > > On Mon, Sep 30, 2019 at 01:41:52PM +0200, Pavel Hrdina wrote: > > > > > > On Mon, Sep 30, 2019 at 09:02:36AM +0200, Peter Krempa wrote: > > > > > > > On Fri, Sep 27, 2019 at 18:17:28 +0100, Daniel Berrange wrote: > > > > > > > > Replace use of the gnulib base64 module with glib's own base64 API family. > > > > > > > > > > > > > > > > Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> > > > > > > > > --- > > > > > > [..] > > > > > > > > > > > > > > > Here I agree with Peter, for this series I would use VIR_FREE() where > > > > > > it's possible and only for glib objects we can use g_autoptr. > > > > > > > > > > > > But eventually I would like to switch to g_autofree and friends in order > > > > > > to eliminate our specific helpers in favor of glib helpers. > > > > > > > > > > > > This also brings a question if we should keep our wrappers for glib or > > > > > > use it directly. For example the string functions that we have. > > > > > > > > > > Where any libvirt code just duplicates something that alrady exists, then > > > > > I think there's no compelling reason to keep it, the best code is code > > > > > that doesn't exist. > > > > > > > > > > I don't want todo too many big bang replacements though, so I think best > > > > > to deprecate existing libvirt code and phase it out incrementally in many > > > > > cases. > > > > > > I agree in case of the other infrastructure for automatic pointers as > > > that will require more changes. > > > > > > In this case I don't see why we shouldn't just replace all use of > > > VIR_AUTOFREE with g_autofree if the idea is to use g_autofree from now > > > on. > > > > Well that's 1500 uses, across 150 files, so quite a big bang conversion. > > It would need to be split up quite alot otherwise it will be a backport > > conflict magnet. Certainly we want to clean this at some point, its just > > a question of timing. > > > > My preference is to focus on things with functional benefit as the higher > > priority. > > Then please stick with VIR_AUTOFREE for any code you plan to introduce. That forces an even bigger switch over at a later date. An incremental conversion is much less painful overall, even if there is a period when there are two styles in use. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
