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

[Richard Smith]

On Thu, Dec 18, 2014 at 2:19 PM, Nico Weber <thakis at chromium.org> wrote:
>
> On Thu, Dec 18, 2014 at 2:01 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> 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.
>>
>
> The bit you quoted says "some identifiers are reserved for use by C ++
> implementations and shall not be used otherwise", but a C++ implementation
> can choose that is going to use a __identifier as part of it's public
> interface, no? Something like "Define __no_exceptions if you want a
> standard library without exceptions" or similar – in this case, user code
> needs to define this macro and it'll be standards-compliant since it's
> using the __identifier as intended by the C++ implementation it uses. Due
> to this, it's difficult to predict which __identifiers are ok to define and
> which aren't. The bit you quoted at least doesn't say "don't define
> __idents", it just says "use __idents only as intended by your C++
> implementation" as far as I can tell.
>

Right. But Clang is not the implementation; the implementation also
includes the standard library, which we don't control, so we can't know
which __names the implementation allows or disallows, in general. Did you
see my other mail proposing a way to fix this (allow user code to define or
use each reserved macro name -- but not both)? That may be imperfect, but
seems like it might be a good heuristic to reduce the noise.


> The other paragraph explicitly says "shall not #define or #undef names
> lexically identical to keywords […]" (, in "C++ programs that use the
> facilities of the C ++ standard library."). I agree that the warning would
> be More Correct if it checked for that too, but it seems like a minor
> detail in practice, as most programs use the C++ standard library – minor
> enough to not revert the warning over it, at least.
>

Well, it's a Warning not an ExtWarn, so it doesn't matter if it warns on
conforming code, so long as it warns on questionable and very-likely-wrong
code.


> (But this is discussion is somewhat pointless now that r224512
> added-Wkeyword-macro back :-) )
>
>
>>
>>
>>> 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/8572d432/attachment.html>