On Mon, Feb 25, 2019 at 11:14:41AM +0000, Daniel P. Berrangé wrote: > On Mon, Feb 25, 2019 at 12:09:41PM +0100, Erik Skultety wrote: > > On Fri, Feb 22, 2019 at 04:43:25PM +0000, Daniel P. Berrangé wrote: > > > On Fri, Feb 22, 2019 at 04:32:27PM +0100, Erik Skultety wrote: > > > > Unfortunately, in order to support the new flags, the last patch introduces an > > > > API breakage as the convention we use for the bindings is to also enforce types > > > > for flags. > > > > > > Yes, unfortunately this need to break ABI is fallout resulting from > > > my decision to make the Go bindings do stricter enum validation that > > > we have had at the C level. > > > > How would this affect the ABI? Both the old and the new enum have the same int > > value 0x01, with the only difference that you could have fed a few more enums > > into the API even though we documented that they were unsupported for that > > usage. > > Previously an application would have done > > dom.ManagedSaveGetXMLDesc(libvirt.DOMAIN_XML_SECURE) > > With your change pushed, this becomes a compile error > > demo.go:20:27 cannot use DOMAIN_XML_SECURE (type DomainXMLFlags) as type DomainSaveImageXMLFlags in argument to dom.ManagedSaveGetXMLDesc > > because the DomainXMLFlags enum type doesn't match the new > DomainSaveImageXMLFlags enum type. Yes, but if it's a compile time error, it's static type checking, isn't that still API breakage? I'd understand if e.g. it was a public structure and the project we'd expand the structure or added padding where the type is still the same, so compilation is okay, but from binary POV it would not... Thanks for clarifying, Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
