On 09/10/2014 06:53 PM, Fam Zheng wrote:
> On Wed, 09/10 17:32, Paolo Bonzini wrote:
>> Il 10/09/2014 17:02, Fam Zheng ha scritto:
>>>> A bit hackish, but I don't have any better idea.
>>>>
>>>> Hmm... what about adding a new member to the visitors for "invalid enum"
>>>> value?  The dealloc visitor could override it to do nothing, while the
>>>> default could abort or set an error.  Would that work?
>>>
>>> The invalid state of enum still needs to be saved in the data.  It is detected
>>> by the input visitor, but should be checked by other visitors (output, dealloc)
>>> later.
>>
>> Yes, that's fine.  The only part where I'm not sure is the special
>> casing of the _MAX enum.
>>
> 
> Yes, it is abusing. Let's add an _INVALID = 0 enum which is much clearer.

If I understand correctly, you mean that for:

{ 'enum': 'Foo', 'data': [ 'one', 'two' ] }

FOO_ONE would now be 1 instead of its current value of 0?

We just barely saw a case where Hu Tao's code was relying on the
implicit value 0 assigned to the first enum in the json file [1]
although I strongly argued that it should be nuked (and so it was fixed
in [2]).  So I could live with reserving 0 for internal use for flagging
parse errors (such as attempting to pass the string 'three' where a Foo
value is expected).

[1] https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01691.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01938.html

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org