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

[Richard Smith]

On Wed, Dec 17, 2014 at 7:58 PM, Nico Weber <thakis at chromium.org> wrote:
>
> On Wed, Dec 17, 2014 at 7:05 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>>
>> 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).
>>
>
> I'm not sure I understand the point here – do you mean the warning should
> only fire if a standard library has been included? In pedantic mode, I
> would expect that people would want to know about stuff that's undefined
> behavior even if they don't happen to include a standard library header at
> the moment.
>

The point is that -Wreserved-id-macro is *more* breaking-the-rules than
-Wkeyword-macro, so I disagree with your argument for removing
-Wreserved-id-macro and keeping -Wkeyword-macro.


> 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.
>>
>
> Some end user code uses them, for example to work around bugs in
> /usr/include headers. I know of one example in Chromium (
> https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/libgtk2ui/gtk2_ui.cc&q=__need_Null&sq=package:chromium&type=cs&l=72
> ) and I found
> https://github.com/asfernandes/firebird/blob/35b06c7892e2440c4f4528b9ecc99969927728e0/src/common/utils.cpp#L35
> (there might be more, but github's search is somewhat hard to operate.)
>
> Having said that, I'm happy with the warning coming back in an improved
> form.
>
>
>> 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/20141218/cc23e14b/attachment.html>