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@redhat.com> ---
[..]
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. 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 :|