From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyzpR-0007Pk-F1 for qemu-devel@nongnu.org; Wed, 18 Nov 2015 05:19:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyzpN-00005d-GW for qemu-devel@nongnu.org; Wed, 18 Nov 2015 05:19:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyzpN-00005Z-B0 for qemu-devel@nongnu.org; Wed, 18 Nov 2015 05:19:01 -0500 From: Markus Armbruster References: <1447836791-369-1-git-send-email-eblake@redhat.com> <1447836791-369-18-git-send-email-eblake@redhat.com> Date: Wed, 18 Nov 2015 11:18:57 +0100 In-Reply-To: <1447836791-369-18-git-send-email-eblake@redhat.com> (Eric Blake's message of "Wed, 18 Nov 2015 01:52:52 -0700") Message-ID: <878u5vvcdq.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: > *** 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". In my private opinion, the one sane way to compile C code with a C++ compiler is wrapping it in extern "C" { ... }. > 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.