On Wed, Dec 17, 2014 at 7:58 PM, Nico Weber <[email protected]> wrote: > > On Wed, Dec 17, 2014 at 7:05 PM, Richard Smith <[email protected]> > wrote: >> >> On Tue, Dec 16, 2014 at 1:17 PM, Nico Weber <[email protected]> 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 < >>> [email protected]> 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 >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> >>>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
