Bug 3885 - Incorrect "invalid suffix on integer constant" error
Summary: Incorrect "invalid suffix on integer constant" error
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 11494 32805 42421 44272 47539 54587 63324 (view as bug list)
Depends on:
Reported: 2001-07-30 14:56 UTC by keith.rollin
Modified: 2018-04-11 13:40 UTC (History)
10 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description keith.rollin 2001-07-30 14:56:00 UTC
I am getting apparently incorrect "invalid suffix on integer constant" errors.  I don't see this myself because I don't have gcc 3.0, but someone I work with does, and I'm able to reproduce the problem with CodeSourcery's Online Test Compilation.

gcc 3.0

Go to  CodeSourcery's Online Test Compilation (<http://www.codesourcery.com/gcc-compile.shtml>). Enter the following into the big text box:

int a[0x00E-0x00A];

Hit "compile with  gcc".  You should get the error message.
Comment 1 keith.rollin 2001-07-30 14:56:00 UTC
Add spaces around the minus sign.
Comment 2 Alexandre Oliva 2001-07-30 20:27:41 UTC
State-Changed-From-To: open->closed
State-Changed-Why: Strange as it may seem, the behavior is correct, and mandated by the C Standard.  0x00E-0x00A is a single preprocessor token, of type pp-number, and it must become a single compiler token, but it can't.  The gotcha is the `E-' sequence, that makes it seem like the exponent notation of floating-point constants.
Comment 3 Sandip 2003-12-09 13:02:54 UTC
I am faching the same bug during compileation of module(Linux Kernel Verson
2.4.20-8). Please explane me about the fix "Add spaces around the minus sign."
 Where to add spaces and  around which minus sign?

Thanks and regards,
Comment 4 Zack Weinberg 2003-12-09 18:18:59 UTC
int a[0x00E - 0x00A];
Comment 5 The gcc-bugs mailing list 2003-12-14 06:15:20 UTC
Not a bug...
Comment 6 The gcc-bugs mailing list 2003-12-14 06:16:17 UTC
So should be resolved-invalid
Comment 7 Andrew Pinski 2009-12-18 01:23:28 UTC
*** Bug 42421 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2009-12-18 01:24:00 UTC
*** Bug 11494 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Pinski 2009-12-18 01:24:34 UTC
*** Bug 32805 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Pinski 2011-01-30 02:47:56 UTC
*** Bug 47539 has been marked as a duplicate of this bug. ***
Comment 11 Andreas Schwab 2012-09-15 12:02:04 UTC
*** Bug 54587 has been marked as a duplicate of this bug. ***
Comment 12 Andrew Pinski 2014-09-22 05:13:03 UTC
*** Bug 63324 has been marked as a duplicate of this bug. ***
Comment 13 Andrew Pinski 2014-09-22 05:13:15 UTC
*** Bug 44272 has been marked as a duplicate of this bug. ***
Comment 14 Zack Weinberg 2018-04-11 13:40:08 UTC
I think we should reopen this bug and treat it as a request to improve the diagnostics.

GCC is correct to reject tokens of the form "0x000E-0x0001", but the accumulation of duplicate bug reports suggests that we could do a better job of explaining what is wrong.  Proposal: whenever we are about to issue the "invalid suffix on (integer/floating) constant" error, if the first character of the "invalid suffix" is + or -, we say instead something like

    error: invalid numeric constant "<entire pp-number token>"
    note: ('+'/'-') after ('e'/'p'/'E'/'P') continues a pp-number
    note: to perform (addition/subtraction), put a space before the ('+'/'-')

Printing the entire pp-number token instead of just the "suffix", mentioning the standardese term "pp-number", and calling the token an "invalid numeric constant" instead of an "invalid integer/floating constant" should clue people in to _why_ this apparently perverse tokenization is happening.