[cfe-dev] #define keyword

[Seth Cantrell]

On Jun 20, 2013, at 2:53 PM, James Dennett <james.dennett at gmail.com> wrote:

> On Thu, Jun 20, 2013 at 10:01 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Thu, Jun 20, 2013 at 9:53 AM, Seth Cantrell <seth.cantrell at gmail.com>
>> wrote:
>>>
>>> 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)?
>>
>>
>> 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.)
>
> 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.

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?