From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz5Ta-00019M-9k for qemu-devel@nongnu.org; Wed, 18 Nov 2015 11:20:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz5TX-000275-2D for qemu-devel@nongnu.org; Wed, 18 Nov 2015 11:20:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz5TW-00026H-Qs for qemu-devel@nongnu.org; Wed, 18 Nov 2015 11:20:50 -0500 References: <1447836791-369-1-git-send-email-eblake@redhat.com> <1447836791-369-18-git-send-email-eblake@redhat.com> <878u5vvcdq.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <564CA55C.4030809@redhat.com> Date: Wed, 18 Nov 2015 09:20:44 -0700 MIME-Version: 1.0 In-Reply-To: <878u5vvcdq.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GJB18OpIhjPjixDcq0gqtVVhDbtHXVkoW" Subject: Re: [Qemu-devel] [PATCH v12 17/36] qapi: Fix c_name() munging List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GJB18OpIhjPjixDcq0gqtVVhDbtHXVkoW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/18/2015 03:18 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> *** WARNING: THE ATTACHED DOCUMENT(S) CONTAIN MACROS *** >> *** MACROS MAY CONTAIN MALICIOUS CODE *** >> *** Open only if you can verify and trust the sender *** >> *** Please contact infosec@redhat.com if you have questions or concern= s ** >=20 > Another one. >=20 >> The method c_name() is supposed to do two different actions: munge >> '-' into '_', and add a 'q_' prefix to ticklish names. But it did >> these steps out of order, making it possible to submit input that >> is not ticklish until after munging, where the output then lacked >> the desired prefix. >> >> The failure is exposed easily if you have a compiler that recognizes >> C11 keywords, and try to name a member '_Thread-local', as it would >> result in trying to compile the declaration 'uint64_t _Thread_local;' >> which is not valid. However, this name violates our conventions >> (ultimately, want to enforce that no qapi names start with single >> underscore), so the test is slightly weaker by instead testing >> 'wchar-t'; the declaration 'uint64_t wchar_t;' is valid in C (where >> wchar_t is only a typedef) but fails with a C++ compiler (where it >> is a keyword). >=20 > Do we support compiling it with a C++ compiler? To sidestep the > question, I'd say "but would fail". I know we require a C++ compiler for qga on Windows, and qga uses qapi, so I think the problem is real; but as I do not have a working setup for compiling qga for windows, I can only speculate. Changing s/fails/but would fail/ is a nice hedge. >=20 > In my private opinion, the one sane way to compile C code with a C++ > compiler is wrapping it in extern "C" { ... }. True - but I don't think that changes the set of C++ keywords inside the extern block, does it? (The thought of context-sensitive keywords makes me cringe for how one would write a sane parser for that language). >=20 >> Fix things by reversing the order of actions within c_name(). >> >> Signed-off-by: Eric Blake >=20 > Again, just commit message polish, can do on merge. >=20 Don't know why you got it on some messages and not others; I also got a round of those pollutions on other threads. It looks like the responsible party has cleaned up their false positives in the meantime, so hopefully we aren't hit by more of the annoyance. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --GJB18OpIhjPjixDcq0gqtVVhDbtHXVkoW 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/ iQEcBAEBCAAGBQJWTKVcAAoJEKeha0olJ0NqysgIAK6lZhTt2rWcFawmOVquOCY8 7tvHXYRoo5Yqscw00mkx4QkB8d4h0HUQRMs92VLUGrHHKoaAeh+bP3TvqWXsTlgO ZUh90/Ac20ayHQxCU9VU7lmzcEXyvFuPj3acugzJELRq0MUb4vio631MhORTU3Q+ n2ZscX5hh0wkAxDK2sfMSav2Xe0E77nZOyiJ7rB/EsfKkJmvAZ754Y86iowbPILS XMznVlANQZbx6mGAjHiM+eDe38MDOc+JwYiqmBAAUFADERUB/3ketn/zdWBIyASz uuvjORcXgK2PAeADiLxuJzHz3/l0SQQu0kS2V8nhj35iuFCNHg7WAIcfyV1bFr0= =Vp78 -----END PGP SIGNATURE----- --GJB18OpIhjPjixDcq0gqtVVhDbtHXVkoW--