On 07/27/2015 01:50 AM, Markus Armbruster wrote:

>>> This, on the other hand, seems valid from the wire format (it will
>>> always be a dictionary).  I guess the problem is that we generate a C
>>> function signature based by calling out each member of the dictionary -
>>> but how do you do that for a union?
> 
> Exactly: the problem is neither conceptual nor the wire API, it's the C
> API we generate.
> 
>>>                                      So I see what you are doing:
>>> marking that this test currently passes the parser, but then causes
>>> problems for generating C code, so we should either reject it up front,
>>> or fix the generator.  The FIXME documents what you will do later in the
>>> series (reject it up front)
> 
> Yes, in PATCH 15.
> 
>>>                             and the TODO documents what we can do down
>>> the road (fix the generator to allow it).
> 
> I figure we'd change the C API not to explode the data type into
> multiple parameters.  We can consider that when we have a use for it.
> 
>> See also 32/47 - events have the same problem.
> 
> I'm afraid I don't see the connection to PATCH 32.

Patch 32 was where I figured out that we have the same problem where the
C code we generate for an event will break if an event tries to use a
union type as its data dictionary; and therefore, this patch would be an
ideal time to add a test for that, and patch 15 would be an ideal time
to tweak events to not allow unions (as the simple fix, where someday
down the road we may relax things to allow unions in both commands and
events).

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