#define keyword

C++11 [macro.names] 17.6.6.3.1 p2 states

A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 3, or to the attribute-tokens described in 7.6.

As I understand it this means a program that does this is ill-formed,
with a diagnostic required. Clang does not produce any diagnostics for
such defines/undefs. Am I correct that a diagnostic is required? This
doesn't sound like it would be too difficult to implement. Is there a
reason not to have clang produce a warning for this (one that wouldn't
trigger in system headers)?

Correction, that's 17.6.4.3.1.

Given that the requirement is buried in the C++ standard library section,
and there isn't any particular reason to ban #define'ing a keyword for
translation units which don't include the standard library, I would assume
that it's only meant to apply to translation units which include the
standard library. (I could be wrong, though.)

-Eli

That's the intention, yes. The behavior of

#define while(x) while(!(x))

is well-defined, so long as you don't use standard library headers in
the same TU.

-- James

Ah, I see; [constraints.overview] covers this. Although it's a bit at
odds with [global.names], which explicitly covers all programs and not
just programs that use the standard library. (And warnings for
[global.names] would be nice as well.)

Since the overview section also states that violating these rules
results in undefined behavior, the spec does not require diagnostics.
I'm wondering if trying to diagnose these issues anyway would be
worthwhile. For example is there likely a lot of code that violates
these rules (and would that make diagnosis more or less desirable)?
For the rules that only apply to TUs that include standard headers is
there a non-hackish way to detect that?

I've seen code that did '#define const' before including headers in
order to work around libraries with poor const correctness. That was C,
not C++, though.

John Bytheway