[libvirt] [GSoC] Code design for scalar and external types

[Andrea Bolognani]

On Wed, 2018-06-13 at 12:59 +0200, Pavel Hrdina wrote:
> On Wed, Jun 13, 2018 at 12:54:54PM +0200, Andrea Bolognani wrote:
> > On Mon, 2018-06-11 at 12:12 +0200, Pavel Hrdina wrote:
> > > That way we can use any existing free function regardless whether it
> > > checks if the variable is NULL or not and without the need to manually
> > > define new type.
> > > 
> > > The only exception would be the virStringList where we would have to use
> > > the different type.
> > 
> > As danpb (CC'd) mentioned in [1], having the vir*Free() function
> > take a double pointer is good because it allows it to also set it
> > to NULL. I will add that any vir*Free() function that doesn't deal
> > gracefully with being passed a NULL pointer is already buggy and
> > should be fixed.
> > 
> > This new proposal would not deal with either, and it seems to me
> > like it would be preferable to stick with the original one and, as
> > a prerequisite, change all vir*Free() functions so that they follow
> > the design outlined above, as doing so would benefit all code that
> > still needs to perform manual memory management as well.
> > 
> > Are there any known issues that would make such an approach not
> > feasible? Would it expand the scope of the project too much?
> 
> You've missed the whole reason for this new proposal.  Yes, we can fix
> our internal vir*Free() functions but this autofree functionality would
> be nice also for types from external libraries where the types have
> their own free function and that we cannot fix.

Fair enough.

Should we have this *in addition* to the "libvirt native" mechanism
that was initially proposed, then? I'm not personally sure whether
that would ultimately lead to a better result, just throwing it out
there for discussion :)

-- 
Andrea Bolognani / Red Hat / Virtualization