On Mon, Feb 19, 2007 at 02:46:43PM +0000, Mark McLoughlin wrote: > > Unfortunately I don't see a good thing to do in > > this case except to change the semantics of virConnectGetType, which > > arguably breaks ABI compatibility. > > > > Suggestions from anyone? > > Okay, suggest: > > 1) Add a new function with a different name which returns an > allocated string. Mark the old function as deprecated. > > 2) Retain the old function, and have a list of likely static strings > which you can return if it matches the string you got from the > remote side, and if not return (and leak) an allocated string
I would go from 2) but keep an array of existing returned entries, so we only keep one list of the set of OS type handled. That list will be finite and relatively short, that should not be a problem. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
