qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v12 17/36] qapi: Fix c_name() munging


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v12 17/36] qapi: Fix c_name() munging
Date: Wed, 18 Nov 2015 18:59:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 11/18/2015 03:18 AM, Markus Armbruster wrote:
>> Eric Blake <address@hidden> 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 address@hidden 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 <address@hidden>
>> 
>> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]