From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz71G-0003eL-7u for qemu-devel@nongnu.org; Wed, 18 Nov 2015 12:59:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz71B-0003gv-7Y for qemu-devel@nongnu.org; Wed, 18 Nov 2015 12:59:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz71B-0003gr-0g for qemu-devel@nongnu.org; Wed, 18 Nov 2015 12:59:41 -0500 From: Markus Armbruster 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> <564CA55C.4030809@redhat.com> Date: Wed, 18 Nov 2015 18:59:37 +0100 In-Reply-To: <564CA55C.4030809@redhat.com> (Eric Blake's message of "Wed, 18 Nov 2015 09:20:44 -0700") Message-ID: <87d1v7kx2u.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain 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: Eric Blake Cc: qemu-devel@nongnu.org, Michael Roth Eric Blake writes: > On 11/18/2015 03:18 AM, Markus Armbruster wrote: >> Eric Blake writes: >> >>> *** 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 concerns ** >> >> Another one. >> >>> 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). >> >> 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. > >> >> 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). The truly sane way to compile C with a C++ compiler is of course "not": compile it with C and link it. The exception is headers. Stick to declaring extern symbols and the types they need. >>> Fix things by reversing the order of actions within c_name(). >>> >>> Signed-off-by: Eric Blake >> >> Again, just commit message polish, can do on merge. >> > > 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. I reported it, and was told it's been fixed.