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. Release: gcc 3.0 How-To-Repeat: 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.
Fix: Add spaces around the minus sign.
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.
Hi 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, Sandip
int a[0x00E - 0x00A];
Not a bug...
So should be resolved-invalid
*** Bug 42421 has been marked as a duplicate of this bug. ***
*** Bug 11494 has been marked as a duplicate of this bug. ***
*** Bug 32805 has been marked as a duplicate of this bug. ***
*** Bug 47539 has been marked as a duplicate of this bug. ***
*** Bug 54587 has been marked as a duplicate of this bug. ***
*** Bug 63324 has been marked as a duplicate of this bug. ***
*** Bug 44272 has been marked as a duplicate of this bug. ***
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.
Please add to "Duplicates" list: - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33547 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45184
*** Bug 33547 has been marked as a duplicate of this bug. ***
*** Bug 45184 has been marked as a duplicate of this bug. ***