On Thu, Dec 18, 2014 at 2:01 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
> On Wed, Dec 17, 2014 at 7:58 PM, Nico Weber <tha...@chromium.org> wrote: >> >> On Wed, Dec 17, 2014 at 7:05 PM, Richard Smith <rich...@metafoo.co.uk> >> wrote: >>> >>> On Tue, Dec 16, 2014 at 1:17 PM, Nico Weber <tha...@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. 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. (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 < >>>> jo...@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@cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>>>> >>>> >>>> _______________________________________________ >>>> cfe-commits mailing list >>>> cfe-commits@cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>>> >>>>
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
