[cfe-dev] #define keyword

[John Bytheway]

On 2013-06-20 15:28, Seth Cantrell wrote:
> 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)?

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