On Sat, Jun 14, 2014 at 06:50:47AM -0600, Eric Blake wrote:
We have a policy of avoiding enum types in structs in our public API, because it is possible for a client to choose compiler options that can change the in-memory ABI of that struct based on whether the enum value occupies an int or a minimal size. But we missed this for virDomainBlockJobInfo. We got lucky on little-endian machines - if the enum fits minimal size (a char), we still end up padding to the next long before the next field; but on big-endian, a client interpreting the enum as a char would always see 0 when the server supplies contents as an int.
Hmm, nasty.
@@ -2537,7 +2544,7 @@ typedef unsigned long long virDomainBlockJobCursor;
typedef struct _virDomainBlockJobInfo virDomainBlockJobInfo; struct _virDomainBlockJobInfo { - virDomainBlockJobType type; + int type; /* virDomainBlockJobType */ unsigned long bandwidth; /* * The following fields provide an indication of block job progress. @cur
I think we can get away with this change from an ABI POV since we're not changing little-endian hosts, and big-endian is screwed already without it. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|