1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-21 22:03:49 +03:00
Eric Blake 99497739d1 docs: publish correct enum values
We publish libvirt-api.xml for others to use, and in fact, the
libvirt-python bindings use it to generate python constants that
correspond to our 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).

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.

The python generator code has had the off-by-one ever since DV
first wrote it years ago, but most of our public enums were immune
because they had an explicit = 0 initializer.  The only affected
enums are:
- virDomainEventGraphicsAddressType (such as
VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31e
(libvirt v0.8.0)
- virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
since commit 9fbaff0 (libvirt v1.2.3)
- virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
03e0e79 (not yet released)

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@redhat.com>
(cherry picked from commit 9b291bbe20c36c0820c6e7cd2bf6229bf41807e8)
2014-06-26 15:51:04 -06:00
..
2013-12-02 10:21:26 +08:00
2014-06-26 15:51:04 -06:00
2014-03-13 06:54:56 +01:00
2013-12-02 11:59:18 -07:00
2013-12-02 10:21:26 +08:00
2014-03-01 23:44:58 +04:00
2014-03-03 17:41:26 +04:00
2013-12-02 10:21:26 +08:00
2014-02-18 14:46:49 +01:00
2014-03-01 23:44:58 +04:00
2009-07-16 15:06:42 +02:00
2014-04-01 15:29:53 +08:00
2009-07-29 09:04:21 +01:00
2013-12-02 10:21:26 +08:00
2013-09-12 17:18:32 +08:00
2013-11-26 18:37:09 +08:00
2014-03-01 23:44:58 +04:00