[libvirt] [PATCH] blockjob: avoid compiler uncertainty in info sizing

[Daniel P. Berrange]

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 :|