On Wed, Oct 05, 2016 at 09:37:52AM +0200, Christophe Fergeau wrote:
> hey,
>
> On Tue, Oct 04, 2016 at 04:30:14PM +0100, Daniel P. Berrange wrote:
> > > +
> > > +/**
> > > + * gvir_config_domain_graphics_listen_address_get_inet_address:
> > > + *
> > > + * Returns the #GInetAddress associated with the #GVirConfigDomainGraphicsListenAddress.
> > > + *
> > > + * Returns: (transfer full): a #GInetAddress.
> > > + *
> > > + */
> > > +GInetAddress *
> > > +gvir_config_domain_graphics_listen_address_get_inet_address(GVirConfigDomainGraphicsListenAddress *listen)
> > > +{
> > > + g_return_val_if_fail(GVIR_CONFIG_IS_DOMAIN_GRAPHICS_LISTEN_ADDRESS(listen), NULL);
> > > +
> > > + const gchar *address = gvir_config_object_get_attribute(GVIR_CONFIG_OBJECT(listen),
> > > + NULL,
> > > + "address");
> > > + return g_inet_address_new_from_string(address);
> > > +}
> >
> > IIUC GInetAddress only supports numeric IP addresses, where as libvirt
> > also allows hostnames anywhere that an IP address is used. So apps
> > using get_inet_address are liable to get NULL returned if we use
> > GInetAddress.
> >
> > So IMHO we should not use GInetAddress as it'd lead to apps which
> > blindly use this API not realising they'll break if someone put a
> > hostname in the XML until it is too late.
>
> Good point. Should we keep _set_inet_address() which would limit what we
> can set, but would not lead to unexpected results depending on the XML
> content, or should we just drop the GInetAddress altogether, and only
> keep the string based API (which is what Visarion initially proposed).
I think I'd just drop GInetAddress completely to avoid confusion.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list