[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