<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 18, 2014 at 2:19 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Dec 18, 2014 at 2:01 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Dec 17, 2014 at 7:58 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Dec 17, 2014 at 7:05 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Dec 16, 2014 at 1:17 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:</span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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 </div></blockquote><div><br></div></span><div>This seems backwards?</div><div><br></div><div>-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.</div><div><br></div><div>C++ [<a href="http://lex.name" target="_blank">lex.name</a>]p3 (introduced by DR, so applying retroactively to all C++ standards) says:</div><div><br></div><div>"[S]ome identifiers are reserved for use by C ++ implementations and shall not be used otherwise; no diagnostic is required.</div><div>— 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.<br></div><div><div>— Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace."<br></div></div><div><br></div><div>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<br></div><div>this Clause, its behavior is undefined." (per [reserved.names]p1).</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div> </div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>(But this is discussion is somewhat pointless now that r224512 added-Wkeyword-macro back :-) )</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In your commit message for r224371 (which hasn't yet hit the mailing list), you say:<br></div><div><br></div><div>"-Wreserved-id-macro warns on</div><div><br></div><div>    #define __need_size_t</div><div><br></div><div>which is more or less public api for glibc headers."</div><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>Some end user code uses them, for example to work around bugs in /usr/include headers. I know of one example in Chromium ( <a href="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" target="_blank">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</a> ) and I found <a href="https://github.com/asfernandes/firebird/blob/35b06c7892e2440c4f4528b9ecc99969927728e0/src/common/utils.cpp#L35" target="_blank">https://github.com/asfernandes/firebird/blob/35b06c7892e2440c4f4528b9ecc99969927728e0/src/common/utils.cpp#L35</a> (there might be more, but github's search is somewhat hard to operate.)</div><div><br></div><div>Having said that, I'm happy with the warning coming back in an improved form.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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.<br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 15, 2014 at 10:39 AM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Mon, Dec 15, 2014 at 10:24:22AM -0800, Nico Weber wrote:<br>
> For the "final(a,b,c)" define: should we warn on that? It doesn't change<br>
> the meaning of the keyword "final" since that doesn't have parameters.<br>
<br>
</span>For C++11 and newer: IMO yes. Otherwise, no.<br>
<span><font color="#888888"><br>
Joerg<br>
</font></span><div><div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div></div>
</div></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></span></div></div></div>
</blockquote></span></div></div></div>
</blockquote></span></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div></div></div>