Question

I am looking for a strange macro definition, on purpose: I need a macro defined in such a way, that in the event the macro is effectively used in compiled code, the compiler will unfailingly produce an error.

The background: Since C11 had introduced several new keywords, and a new C++11 standard also added a few, I would like to introduce a header file in my projects (mostly using C89/C95 compilers with a few additions) to force developers to refrain from using these new keywords as identifier names, unless, of course, they are recognized as keywords in the intended fashion.

In the ancient past, I did this for new like this:

#define new *** /* C++ keyword, do not use */

And yes, it worked. Until it didn’t, when a programmer forgot the underscore in a parameter name:

void myfunction(uint16_t new parameter);

I used variants since, but I’ve never been challenged again.

Now I intend to create a file with all keywords not supported by various compilers, and I’m looking for a dependable solution, at best with a not too confusing error message. “Syntax error” would be OK, but “parameter missing” would be confusing already.
I’m thinking along the lines of

#define atomic +*=*+ /* C11 derived keyword; do not use */

and aside from my usual hesitation, I’m quite sure that any use (but not the definition) of the macro will produce an error.

EDIT: To make it even more difficult, MISRA will only allow the use of the basic source and execution character set, so @ or $ are not allowed.

But I’d like to ask the community: Do you have a better macro value? As effective, but shorter? Or even longer but more dependable in some strange situation? Or a completely different method to generate an error (only using the compiler, please, not external tools!) when a “discouraged” identifier is used for any purpose?

Disclaimer:
And, yes, I know I can use a grep or a parser to run on a nightly build, and report the warnings it finds. But dropping an immediate error on the developers desk is quicker, and certain to be fixed before checking in.

Answer 1

If the sport is for the shortest tokensequence that always produces an error, any combination of two 1 character operators that can’t legally occur together, but

• don’t use ({ or }) because gcc has a special meaning for that
• don’t use any sort of unbalanced parentheses because they can lead you far away until the error is recognized
• don’t use < or > because they could match template parameters for C++
• don’t use prefix operators as second character
• don’t use postfix operators as first character

This leave some possibilities

• .., .| and other combinations with . since . expects a following identifier
• &|, &/, &^, &,, &;
• !|, !/, !^, !,, !;

But actually to be more user friendly I’d also first place a _Pragma in it so the compiler would also spit a warning.

#define atomic _Pragma("message \"some instructive text that you should read\"") ..