[libvirt] [libvirt-glib 1/5] gconfig: Fix gvir_config_domain_os_get_boot_devices() API doc

Christophe Fergeau cfergeau at redhat.com
Tue Feb 4 12:49:44 UTC 2014


On Tue, Feb 04, 2014 at 12:03:21PM +0000, Daniel P. Berrange wrote:
> On Tue, Jan 21, 2014 at 11:42:54AM +0100, Christophe Fergeau wrote:
> > The elements of the returned list are integer enum values, so they cannot
> > be unreffed.
> > ---
> >  libvirt-gconfig/libvirt-gconfig-domain-os.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/libvirt-gconfig/libvirt-gconfig-domain-os.c b/libvirt-gconfig/libvirt-gconfig-domain-os.c
> > index 03c8a85..b922a0e 100644
> > --- a/libvirt-gconfig/libvirt-gconfig-domain-os.c
> > +++ b/libvirt-gconfig/libvirt-gconfig-domain-os.c
> > @@ -267,8 +267,7 @@ static gboolean add_boot_device(xmlNodePtr node, gpointer opaque)
> >   * @os: a #GVirConfigDomainOs
> >   *
> >   * Gets the list of devices attached to @os. The returned list should be
> > - * freed with g_list_free(), after its elements have been unreffed with
> > - * g_object_unref().
> > + * freed with g_list_free().
> >   *
> >   * Returns: (element-type LibvirtGConfig.DomainOsBootDevice) (transfer full):
> >   * a newly allocated #GList of #GVirConfigDomainOsBootDevice.
> 
> Do you know if GIR cares about this distinction ? ie should we be changing
> 'transfer full' to 'transfer container', or is it assumed that these two
> annotations are identical when the element type is a scalar (non-object)
> type. I'm guessing the distinction doesn't matter, so ACK unless you
> know something to the contrary.

Actually, I don't know, though I'd indeed expect both to behave the same on
scalar types. I tried asking on #introspection if there's a difference.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140204/c0794098/attachment-0001.sig>


More information about the libvir-list mailing list