From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJi7X-0005Ld-IH for qemu-devel@nongnu.org; Mon, 27 Jul 2015 09:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJi7U-0001Lf-Lh for qemu-devel@nongnu.org; Mon, 27 Jul 2015 09:07:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJi7U-0001L5-EE for qemu-devel@nongnu.org; Mon, 27 Jul 2015 09:07:04 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-15-git-send-email-armbru@redhat.com> <55AE3E6D.4000008@redhat.com> <55B1013F.1030704@redhat.com> <87fv4at4xj.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55B62CF0.2050808@redhat.com> Date: Mon, 27 Jul 2015 07:06:56 -0600 MIME-Version: 1.0 In-Reply-To: <87fv4at4xj.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oCajUDGMFxbSbBwIxNNjQj10tl5gplLR9" Subject: Re: [Qemu-devel] [PATCH RFC v2 14/47] qapi-tests: New tests for union, alternate command arguments List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oCajUDGMFxbSbBwIxNNjQj10tl5gplLR9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? >=20 > Exactly: the problem is neither conceptual nor the wire API, it's the C= > API we generate. >=20 >>> 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 fron= t, >>> or fix the generator. The FIXME documents what you will do later in = the >>> series (reject it up front) >=20 > Yes, in PATCH 15. >=20 >>> and the TODO documents what we can do dow= n >>> the road (fix the generator to allow it). >=20 > 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. >=20 >> See also 32/47 - events have the same problem. >=20 > 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). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --oCajUDGMFxbSbBwIxNNjQj10tl5gplLR9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVtiz2AAoJEKeha0olJ0NqoaUH/39KUn3QBn6bB8QpBbezXRLT x4tBw18e+39QCd1udDeOvm4/DusEIgw24XPFH6kcmu96Lpjmg/oadbuV5i/8vNWN DN20W3Ke7Nz1PZNOhU398vm42Dg2M4gx1asyPKuVfCBuAutxTp7Ko1KyOL4W694a tp7Nf/0XE/DJt2dUb2B5NAhDjZw6MsyjGbJb11ncM0qb04JKpcxTL+mFTpLMnbGq 07t53WYb/L06n8bELw/kWQxaJ4iA+jg2BOzjBKKnmEuINtQ4p8u30gYDQudulsAT tJ4gKDLlGh6K0gjuO3JWBvRw/nQxxhlvghOWzWN4e9kU3Q+shuv1CBylewbdrxo= =TdZU -----END PGP SIGNATURE----- --oCajUDGMFxbSbBwIxNNjQj10tl5gplLR9--