This testcase: int a = 0xe+100; Produces a diagnostic message that would surprise most users: foo.c:1:9: error: invalid suffix "+100" on integer constant I'm not sure what the standard says about ambiguity between the hex float notation and the regular + operator, but many users are going to think of this behavior as a parser bug.
(In reply to comment #0) > but many users are going to think of this behavior as > a parser bug. This is more of a tokenizer error rather than a parser error. Anyways 2.95.3 gives: t.c:1: missing white space after number `0xe' I wonder if we should accept this code for -std=c89.
Subject: Re: New: simple hexadecimal number parsed as C99 hex float On Mon, 21 Nov 2005, bernie at develer dot com wrote: > This testcase: > > int a = 0xe+100; 0xe+100 is a single preprocessing number. If the end of <http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html> is unclear, please let us know how we could have improved it so that you would have realised it applies to this situation and so there is no bug.
(In reply to comment #2) > 0xe+100 is a single preprocessing number. If the end of > <http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html> is unclear, > please let us know how we could have improved it so that you would have > realised it applies to this situation and so there is no bug. We could handle it like we do for >> in nested template declarations: split the token and try reparsing the expression with the "other" meaning. If it works, give the friendly error message ("maybe you meant 0xe + 100?").
Confirmed, as a diagnostic issue only. I am going to mark this as a regression even though I know that the preprocessor was rewritten between 2.95.3 and 3.0.x.
Downgraded to P5, as this will never be a release-critical issue.
Won't fix in GCC-4.0.x. Adjusting milestone.
Closing 4.1 branch.
Closing 4.2 branch.
GCC 4.3.4 is being released, adjusting target milestone.
GCC 4.3.5 is being released, adjusting target milestone.
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
Confirmed on gcc 4.6.3.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed
GCC 6 branch is being closed
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Something like this should improve the diagnostic, note the patch needs to be improved for wrapping: diff --git a/libcpp/expr.cc b/libcpp/expr.cc index 6e5bf68eae9..f70be382dd4 100644 --- a/libcpp/expr.cc +++ b/libcpp/expr.cc @@ -728,7 +728,7 @@ cpp_classify_number (cpp_reader *pfile, const cpp_token *token, else { cpp_error_with_line (pfile, CPP_DL_ERROR, virtual_location, 0, - "invalid suffix \"%.*s\" on floating constant", + "invalid suffix \"%.*s\" on floating constant (maybe missing a space)", (int) (limit - str), str); return CPP_N_INVALID; } @@ -753,7 +753,7 @@ cpp_classify_number (cpp_reader *pfile, const cpp_token *token, if ((result & CPP_N_DFLOAT) && radix != 10) { cpp_error_with_line (pfile, CPP_DL_ERROR, virtual_location, 0, - "invalid suffix \"%.*s\" with hexadecimal floating constant", + "invalid suffix \"%.*s\" with hexadecimal floating constant (maybe missing a space)", (int) (limit - str), str); return CPP_N_INVALID; } @@ -789,7 +789,7 @@ cpp_classify_number (cpp_reader *pfile, const cpp_token *token, else { cpp_error_with_line (pfile, CPP_DL_ERROR, virtual_location, 0, - "invalid suffix \"%.*s\" on integer constant", + "invalid suffix \"%.*s\" on integer constant (maybe missing a space)", (int) (limit - str), str); return CPP_N_INVALID; }
GCC 10 branch is being closed.