<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 17, 2014 at 4:03 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</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 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 class=""><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>I would like to have something like -Wreserved-id-macro eventually, but it's really hard to differentiate between uses of internal C++ implementation details (calling __builtin_foo()) and user defined names that are not part of "the implementation" (compiler + stdlib). This is partially covered by the C++ standard in [global.names]p1:</div><div><br></div><div>"""</div><div><div>Certain sets of names and function signatures are always reserved to the implementation:</div><div>— Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase</div><div>letter (2.12) is reserved to the implementation for any use.</div><div>— Each name that begins with an underscore is reserved to the implementation for use as a name in the</div><div>global namespace.</div></div><div>"""</div><div><br></div><div>It says nothing about macros, though, and this is such a hard problem that it's not clear to me that the committed implementation is worth having.</div></div></div></div></blockquote><div><br></div><div>"for any use" is intended to include "for use as a macro".</div><div><br></div><div>For reserved identifiers, I think a reasonable heuristic might be:</div><div><br></div><div>* declaring any (non-macro) entity with a reserved identifier gets a warning</div><div>* using any such entity does not get a warning</div><div>* #defining a macro with a reserved name does not get a warning (we assume it's being used to configure a system header)</div><div>* expanding a macro with a reserved name gets a warning *unless* the macro was defined in a system header</div><div><br></div><div>So: you can define reserved names as macros to parameterize system headers, and system headers can give you macros with reserved names for you to use, but you can't use macros with reserved names for your own internal purposes.</div></div></div></div>