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>
> > > ---
> > > bootstrap.conf | 1 -
> > > src/conf/virsecretobj.c | 38 +++++++------------------------
> > > src/libvirt_private.syms | 1 -
> > > src/libxl/libxl_conf.c | 3 +--
> > > src/qemu/qemu_agent.c | 9 +++-----
> > > src/qemu/qemu_command.c | 5 ++--
> > > src/qemu/qemu_domain.c | 8 +++----
> > > src/secret/secret_driver.c | 1 -
> > > src/storage/storage_backend_rbd.c | 4 +---
> > > src/util/virstring.c | 21 -----------------
> > > src/util/virstring.h | 2 --
> > > tools/virsh-secret.c | 17 ++++----------
> > > 12 files changed, 22 insertions(+), 88 deletions(-)
> >
> > [...]
> >
> > > @@ -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.
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
