On Wed, Sep 17, 2008 at 08:36:50AM -0400, Konrad Rzeszutek wrote: > On Wed, Sep 17, 2008 at 11:43:19AM +0100, Richard W.M. Jones wrote: > > On Tue, Sep 16, 2008 at 04:45:09PM -0400, Ben Guthro wrote: > > > My concern is that adding to the nodeinfo struct breaks the API - such > > > that the structs will be different sizes between versions. > > > > Extending this structure would break the A _B_ I. > > > > <aside> > > > > Specifically, because of dynamic linking you can have two situations > > arising: > > > > (1) caller compiled against old libvirt links to newer libvirt > > (2) caller compiled against new libvirt links to older libvirt > > > > You cannot tell just from the pointer passed to virNodeGetInfo how > > large the caller's structure is, so you could end up overwriting > > memory beyond the structure in case (1). > > > > In calls such as virDomainInterfaceStats, I fixed this by having the > > caller pass both a pointer to the structure and the size of the > > caller's structure. This allows us to expand the structure in future > > in a way which won't break either case (1) or (2). I would encourage > > people designing future libvirt APIs which take a pointer to a > > How about just having a virVersion field that would tell you what > version of the struct it is? This being on top of the check you have. The more I think about this, having the caller pass both the pointer to the structure and the version would guard against the issues you mentioned (new fields added to the structure) and the case where a function prototype gets its arguments swapped around for example, and also for: > That way you can also guard against functions that change the number of > arguments, which would not change the size of the caller's structure. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list