From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5cuE-0003SH-Bv for qemu-devel@nongnu.org; Fri, 11 Jul 2014 11:38:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5cu8-0000av-JM for qemu-devel@nongnu.org; Fri, 11 Jul 2014 11:38:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5cu8-0000a7-BY for qemu-devel@nongnu.org; Fri, 11 Jul 2014 11:38:32 -0400 Message-ID: <53C004F2.1000602@redhat.com> Date: Fri, 11 Jul 2014 09:38:26 -0600 From: Eric Blake MIME-Version: 1.0 References: <20140708141728.412a3f1c@redhat.com> <87fvi9i8tx.fsf@blackfin.pond.sub.org> <20140710103641.31b658c0@redhat.com> <87vbr4vtwp.fsf@blackfin.pond.sub.org> In-Reply-To: <87vbr4vtwp.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6w8a9s7GFvunqKK5pJSE0B8mihK3VWjeg" Subject: Re: [Qemu-devel] [PATCH] scripts: qapi-event.py: support vendor extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Luiz Capitulino Cc: qemu-devel , wenchaoqemu@gmail.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6w8a9s7GFvunqKK5pJSE0B8mihK3VWjeg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/11/2014 08:42 AM, Markus Armbruster wrote: >>> Can anybody think of a use of c_var() that needs '.' preserved? >> >> Doing the replace in c_var() breaks some struct accesses in the genera= ted >> code. I didn't look deeper to determine the users though. >=20 > Feels like a misuse of c_var() to me. >=20 > Dig, dig... aha. generate_visit_struct_fields() joins QAPI names > separated by '.', and passes the result to c_var(). I expect such code= > to break when one of the names contains '.'. >=20 > It does indeed; try the appended patch to see it yourself. It generate= s >=20 > struct VersionInfo > { > struct=20 > { > int64_t major; > int64_t minor; > int64_t micro; > } qemu; Wait a minute. Isn't this one of the three cases of nested structs, where we were already arguing that nested structs are evil if we are going to introduce a fuller syntax for optional argument defaults? > struct=20 > { > int64_t major; > int64_t minor; > int64_t micro; > } __com.redhat.crap; > char *package; > }; >=20 > Conclusion: this is simply a bug that needs fixing. >=20 >=20 > diff --git a/qapi/common.json b/qapi/common.json > index 4e9a21f..74ccde3 100644 > --- a/qapi/common.json > +++ b/qapi/common.json > @@ -52,6 +52,7 @@ > ## > { 'type': 'VersionInfo', > 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'}, > + '__com.redhat.crap': {'major': 'int', 'minor': 'int', 'micr= o': 'int'}, > 'package': 'str'} } And the fix may be as simple as ditching support for nested structs in the first place, and rewriting this as: { 'type': 'VersionDetails', 'data': { major': 'int', 'minor': 'int', 'micro': 'int'} } { 'type': 'VersionInfo', 'data': {'qemu': 'VersionDetails', '__com.redhat.crap': 'VersionDetails', 'package': 'str' } } But the fact that we are still discussing makes it obvious - this is 2.2 material. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --6w8a9s7GFvunqKK5pJSE0B8mihK3VWjeg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTwATzAAoJEKeha0olJ0Nq27kH/2oEnPyJRbX4lcwY90+6Zsm/ G+PNiBYYBH30eqgXVKXFJNBc6RI50mpR8mPaBPDqOnMzBUncDeHT+9BP6vq2Sq4e jLt4X0LZE5hIHk7Xu4NKIWuPvK5tGoyKYUw6IZuk2iEVaORzAAV41CNnjTIEZUQr x4cXiK8q4MLQBuy8Qjq7v32AV0WKdICoAAsVKEmsDC6I6A5LpTNciZ5Xw0M2lIdF 13vS51/VyUkyrQ+sdKZmt3NjRrQX64SHOZJf2/xFG6AA2JBwqtCK7T9M5HlmHCA5 TzIAYv0ShR86OnGVINCD/ID6XzlZXTXXMH2V2vX0gjcyGh9gbXqdp0Rp3Ur4+3s= =2k2L -----END PGP SIGNATURE----- --6w8a9s7GFvunqKK5pJSE0B8mihK3VWjeg--