[Libvir] ABI compatibility question: static strings returned from some functions
We have some functions such as virConnectGetType which are defined to return statically allocated strings: /** * virConnectGetType: * @conn: pointer to the hypervisor connection * * Get the name of the Hypervisor software used. * * Returns NULL in case of error, a static zero terminated string otherwise. */ const char * virConnectGetType(virConnectPtr conn) [...] This is all well and good in the typical local case, but when working over a remote connection the string we return is allocated and requires freeing at some point. 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? Rich. garbage.collection++ -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
Hey, On Mon, 2007-02-19 at 14:44 +0000, Richard W.M. Jones wrote:
We have some functions such as virConnectGetType which are defined to return statically allocated strings:
/** * virConnectGetType: * @conn: pointer to the hypervisor connection * * Get the name of the Hypervisor software used. * * Returns NULL in case of error, a static zero terminated string otherwise. */ const char * virConnectGetType(virConnectPtr conn) [...]
This is all well and good in the typical local case, but when working over a remote connection the string we return is allocated and requires freeing at some point.
Uggh.
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 Cheers, Mark.
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/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Tue, 2007-02-20 at 23:32 -0500, Daniel Veillard wrote:
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.
I was suggesting both 1) and 2), btw. Cheers, Mark.
participants (3)
-
Daniel Veillard -
Mark McLoughlin -
Richard W.M. Jones