Eric Blake <ebl...@redhat.com> 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 info...@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 <ebl...@redhat.com>
Again, just commit message polish, can do on merge.
