[LLVMbugs] [Bug 18371] New: Warn on reserved symbol names

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Jan 3 12:53:39 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18371

            Bug ID: 18371
           Summary: Warn on reserved symbol names
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jj at medical-insight.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The C++ (11 is the one I checked) standard - in section 17.6.4.3 spells out the
rules about a number of symbol names that are reserved for the implementation.
For example; names containing double underscore, names starting with underscore
in the global namespace, names from the Standard C library declared with
external linkage, etc (there are also some reserved names imported by the
inclusion of the C/Posix standard(s) I believe).

It would be great if clang could warn on uses of symbol names (including
macros) that clash with names reserved by the standard.

This warning whould probably not be part of something like -Wall or -Wextra
since it will probably be quite noisy for many code bases (at least I know that
I've seen my fair share of codebases that happily uses standard-reserved names
all over the place) and there's also the fact that implementors of things like
STL would *not* want this warning enabled for their code.
But if it could just be something that one could explicitly enable (like
-Wreserved-identifier or something) as well as being part of -Weverything then
that would be a real help in getting a lot of code cleaned up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140103/db6e9642/attachment.html>


More information about the llvm-bugs mailing list