blockjob: avoid compiler uncertainty in info sizing

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.

* include/libvirt/libvirt.h.in (virDomainBlockJobInfo): Enforce
particular sizing.

Signed-off-by: Eric Blake <eblake@redhat.com>

diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 10ce4a172d9f153b2b0d5a7e57f6a53a2cd8e6eb..dc88c401c3c936ab72634a998e71896b43be1db5 100644 (file)
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -2544,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