Re: [libvirt] [PATCH 06/11] util: use glib base64 encoding/decoding APIs

On Mon, 2019-09-30 at 13:56 +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: > > > > > @@ -698,23 +697,17 @@ virSecretObjSaveConfig(virSecretObjPtr obj) > > > > > int > > > > > virSecretObjSaveData(virSecretObjPtr obj) > > > > > { > > > > > - char *base64 = NULL; > > > > > - int ret = -1; > > > > > + g_autofree char *base64 = NULL; > > > > > > > > I'm not a fan of adding another style here. Either use VIR_FREE(), or > > > > convert all VIR_FREE to g_autofree first. > > > > > > > > I'm aware it will be unavoidable to use the glib auto pointer macro for > > > > complex types but we should at least here where it's interchangable have > > > > some kind of consistency. > > > > > > 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. > > Agreed, for now let's keep all the wrappers but eventually we can remove > them to make the code cleaner. Note that we should be able to use VIR_AUTOPTR() instead of g_autoptr() even for objects, by simply registering the same GLib-provided free function with our own macros. That way we could keep using VIR_AUTO* everywhere and then, when we're ready, mechanically switch everything to g_auto* in one fell swoop, without having any point in time where the two styles are coexisting.