From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlyyo-0000LN-BE for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:47:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zlyyi-0008Qc-Ty for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:46:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlyyi-0008QB-NG for qemu-devel@nongnu.org; Tue, 13 Oct 2015 08:46:52 -0400 References: <1443930073-19359-1-git-send-email-eblake@redhat.com> <1443930073-19359-12-git-send-email-eblake@redhat.com> <8737xgqe19.fsf@blackfin.pond.sub.org> <561BDE44.4000407@redhat.com> <87fv1fgs9g.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <561CFD36.5020106@redhat.com> Date: Tue, 13 Oct 2015 06:46:46 -0600 MIME-Version: 1.0 In-Reply-To: <87fv1fgs9g.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4eSixMWbEhhU731ObHGDha2WQx9JOMSFQ" Subject: Re: [Qemu-devel] [PATCH v7 11/14] qapi: Move duplicate member checks to schema check() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Michael Roth , marcandre.lureau@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4eSixMWbEhhU731ObHGDha2WQx9JOMSFQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/13/2015 01:08 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> On 10/12/2015 09:53 AM, Markus Armbruster wrote: > [...] >>> It would be simpler if we could make C clash only when QMP clashes. >> >> If a QMP clash always caused a C clash, life would be a bit simpler. W= e >> aren't going to get there (because in a flat union, hiding the members= >> of the branch type behind a single pointer means those members don't >> clash with any C names of the overall union), but I can certainly try = to >> make the comments explain what is going on. >=20 > (1) If QMP clashed exactly when C clashed, we'd have to think only abou= t > one of them, and the C compiler would check for clashes statically. Although deferring the error about the clash until compile time is a bit long, compared to reporting the clash at generator time. >=20 > (2) If a QMP clash implied a C clash, we'd only have to think about C, > and the C compiler would check statically. >=20 > (3) If a C clash implied a QMP clash, we'd only have to think about QMP= =2E >=20 > (4) If they can clash independently, we need to think about both > independently. >=20 > We currently have (4), and having to juggle both QMP and C in my mind > has been taxing. >=20 > My remark was about (3): C clashes only when QMP clashes <=3D> C clash > implies QMP clash. >=20 > Your remark was about (2). More useful than (3), but as you say not > feasible. >=20 > Do you think we can get to (3)? C clash that does not imply a QMP clash: { 'union':'U', 'data':{ 'a':'int', 'A':'str' } } C clash (the implicit enum has two U_KIND_A values) but not a QMP clash ('a' and 'A' don't even appear in QMP; and even if they did, they are distinct in C as branch names). Might be possible to avoid the C clash by munging case labels of the generated enum differently, but I'm not sure it is worth the effort. QMP clash that does not (currently) imply a C clash (using abbreviated notation): { 'union':'U', 'base':{ 'type':'Enum', 'member':'int' }, 'discriminator':'type', 'data':{ 'branch':{ 'member':'str' } } } QMP clash (the field 'member' is part of the base type, and also part of the 'branch' variant type), but not a C clash (because the C layout accesses the branch through a box named 'branch'). But we cannot just remove the boxing, either, because then we'd have a clash in C that is NOT a clash in QMP: { 'union':'U', 'base':{ 'type':'Enum' }, 'discriminator':'type', 'data':{ 'branch1':{ 'member':'str' }, 'branch2': { 'member':'int' } } } If the two 'member' fields were at the same C level as 'type', then we could use C collisions to detect a QMP clash between a variant's members and the non-variant fields - but it also has the drawback of declaring a C collision between the two branches. So no, I don't think we can get to (3). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --4eSixMWbEhhU731ObHGDha2WQx9JOMSFQ 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/ iQEcBAEBCAAGBQJWHP02AAoJEKeha0olJ0NqwV4H/1ccqYjTyAGJHAMSq6s+2DZY GhcbkSn4s1b+QCNfvaPCgVZVAp8vxIVzcJnDQnrYJzY0Gg5uD5ubtnjPuw2WmqpF w7RQFkRdWw3z9e9wW5qDsRcq60gqRqVEYrv53PB7j85rL0xSJz9XJouTXJ/aY21j EqSeO3IWWmuej61P+thx/Kab4iHBSzkcd8EQ6gpwefIOmPwXjhvg4i/DvPAyz76I iTNX34ONeYLLwfjQwNgjUWXb2QocIhCY5wIv0UOSvnyU8AG4QmwXdtpK+XqQ0kU7 qVbISvmrR+JDmcHLtBZtcSQJkC/4cTtyyjJGn4ywxJ38wOFUT3emIZDp5/NBdj4= =reIK -----END PGP SIGNATURE----- --4eSixMWbEhhU731ObHGDha2WQx9JOMSFQ--