[llvm-bugs] [Bug 26910] New: Enhance diagnostic for "Invalid suffix on integer constant" for hexadecimal constants ending in E

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Mar 10 23:19:16 PST 2016


https://llvm.org/bugs/show_bug.cgi?id=26910

            Bug ID: 26910
           Summary: Enhance diagnostic for "Invalid suffix on integer
                    constant" for hexadecimal constants ending in E
           Product: clang
           Version: 3.8
          Hardware: Macintosh
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: christophe at dinechin.org
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider the following snippet of code:

    int x = 0xAE+foo;

clang currently issues the diagnostic:

    /tmp/glop.c:1:11: error: invalid suffix '+foo' on integer constant

This is actually correct, because this is treated as a single preprocessing
token. See example in 2.4.3 in original C++ standard that states:

    4 [Example: The program fragment 0xe+foo is parsed as a preprocessing
number token (one that is not a valid floating or integer literal token), even
though a parse as three preprocessing tokens 0xe, +, and foo might produce a
valid expression (for example, if foo were a macro defined as 1). Similarly,
the program fragment 1E1 is parsed as a preprocessing number (one that is a
valid floating literal token), whether or not E is a macro name. — end example
]

However, I think it is desirable to emit a better diagnostic in this specifc
case, since I believe it is very confusing for the average programmer.

-- 
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/20160311/0454e960/attachment.html>


More information about the llvm-bugs mailing list