We publish libvirt-api.xml for others to use, and in fact, the
libvirt-python bindings use it to generate enum values. However,
we had an off-by-one bug that any enum that relied on C's rules
for implicit initialization of the first enum member to 0 got
listed in the xml as having a value of 1 (and all later members
of the enum were equally botched).
Affected are:
- virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
since libvirt TBD
- virDomainEventGraphicsAddressType (such as
VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since libvirt TBD
- virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since libvirt TBD
The fix is simple - since we add one to the previous value when
encountering an enum without an initializer, the previous value
must start at -1 so that the first enum member is assigned 0.
Thanks to Nehal J Wani for reporting the problem on IRC, and
for helping me zero in on the culprit function.
* docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
values.
Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>
---
I'm going to touch up the commit message before pushing, once I
do enough research on which versions of libvirt were impacted;
but I just got interrupted, so I'm posting this now to get the
review started.
docs/apibuild.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/apibuild.py b/docs/apibuild.py
index 5250c5a..30e224d 100755
--- a/docs/apibuild.py
+++ b/docs/apibuild.py
@@ -1312,7 +1312,7 @@ class CParser:
name = None
self.comment = None
comment = ""
- value = "0"
+ value = "-1"
while token is not None:
if token[0] == "sep" and token[1] == "{":
token = self.token()
--
1.9.3
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list