r224012 - Emit warning if define or undef reserved identifier or keyword.

[Richard Smith]

On Tue, Dec 16, 2014 at 1:17 PM, Nico Weber <thakis at chromium.org> wrote:
>
> Ok, I moved -Wkeyword-macro into -pedantic in r224371. I also removed
> -Wreserved-id-macro in the same revision, as it's not covered by the
> standards bit you cited
>

This seems backwards?

-Wreserved-id-macro is (was) warning on code that is ill-formed.
-Wkeyword-macro is warning on code that has undefined behavior (only) if a
standard library header is #included.

C++ [lex.name]p3 (introduced by DR, so applying retroactively to all C++
standards) says:

"[S]ome identifiers are reserved for use by C ++ implementations and shall
not be used otherwise; no diagnostic is required.
— Each identifier that contains a double underscore __ or begins with an
underscore followed by an uppercase letter is reserved to the
implementation for any use.
— Each identifier that begins with an underscore is reserved to the
implementation for use as a name in the global namespace."

Aaron's quote of [macro.names]p2 applies only to "C++ programs that use the
facilities of the C ++ standard library." (per [constraints.overview]p1),
and "If a program declares or defines a name in a context where it is
reserved, other than as explicitly allowed by
this Clause, its behavior is undefined." (per [reserved.names]p1).


In your commit message for r224371 (which hasn't yet hit the mailing list),
you say:

"-Wreserved-id-macro warns on

    #define __need_size_t

which is more or less public api for glibc headers."

I don't agree with your example; these __need_* macros exist only to allow
communication between the /usr/include headers and the compiler-provided
<stddef.h>, because /usr/include needs to include a subset of <stddef.h>
depending on which of its headers is included. They're not for end-users,
and these warnings should be suppressed in system headers.

That said, there are a bunch of reserved macro names that *is* part of the
glibc public API, such as the _*_SOURCE macro family. If we reinstate this
warning, we should whitelist those ones at least.

On Mon, Dec 15, 2014 at 10:39 AM, Joerg Sonnenberger <
> joerg at britannica.bec.de> wrote:
>>
>> On Mon, Dec 15, 2014 at 10:24:22AM -0800, Nico Weber wrote:
>> > For the "final(a,b,c)" define: should we warn on that? It doesn't change
>> > the meaning of the keyword "final" since that doesn't have parameters.
>>
>> For C++11 and newer: IMO yes. Otherwise, no.
>>
>> Joerg
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141217/13dea652/attachment.html>