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

[Eric Blake]

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).

> 
>> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature