[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals

[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Joseph Myers <jsm28@gcc.gnu.org>:

https://gcc.gnu.org/g:8f51cf38bb9628546effe66c070188d10f80b5ca

commit r12-580-g8f51cf38bb9628546effe66c070188d10f80b5ca
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu May 6 23:20:35 2021 +0000

    preprocessor: Fix pp-number lexing of digit separators [PR83873, PR97604]

    When the preprocessor lexes preprocessing numbers in lex_number, it
    accepts digit separators in more cases than actually permitted in
    pp-numbers by the standard syntax.

    One thing this accepts is adjacent digit separators; there is some
    code to reject those later, but as noted in bug 83873 it fails to
    cover the case of adjacent digit separators within a floating-point
    exponent.  Accepting adjacent digit separators only results in a
    missing diagnostic, not in valid code being rejected or being accepted
    with incorrect semantics, because the correct lexing in such a case
    would have '' start the following preprocessing tokens, and no valid
    preprocessing token starts '' while ' isn't valid on its own as a
    preprocessing token either.  So this patch fixes that case by moving
    the error for adjacent digit separators to lex_number (allowing a more
    specific diagnostic than if '' were excluded from the pp-number
    completely).

    Other cases inappropriately accepted involve digit separators before
    '.', 'e+', 'e-', 'p+' or 'p-' (or corresponding uppercase variants).
    In those cases, as shown by the test digit-sep-pp-number.C added, this
    can result in valid code being wrongly rejected as a result of too
    many characters being included in the pp-number.  So this case is
    fixed by terminating the pp-number at the correct character according
    to the standard.  That test also covers the case where a digit
    separator was followed by an identifier-nondigit that is not a
    nondigit (e.g. a UCN); that case was already handled correctly.

    Bootstrapped with no regressions for x86_64-pc-linux-gnu.

    libcpp/
            PR c++/83873
            PR preprocessor/97604
            * lex.c (lex_number): Reject adjacent digit separators here.  Do
            not allow digit separators before '.' or an exponent with sign.
            * expr.c (cpp_classify_number): Do not check for adjacent digit
            separators here.

    gcc/testsuite/
            PR c++/83873
            PR preprocessor/97604
            * g++.dg/cpp1y/digit-sep-neg-2.C,
            g++.dg/cpp1y/digit-sep-pp-number.C: New tests.
            * g++.dg/cpp1y/digit-sep-line-neg.C, g++.dg/cpp1y/digit-sep-neg.C:
            Adjust expected messages.

[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |12.0
             Status|NEW                         |RESOLVED

--- Comment #3 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Fixed for GCC 12.