public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/106248] [11 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels
Date: Wed, 07 Sep 2022 17:49:27 +0000	[thread overview]
Message-ID: <bug-106248-4-7eZQDLSEBb@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106248-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:3d17eaabb3e771472d7bfa1f654564a5db57f5ef

commit r11-10241-g3d17eaabb3e771472d7bfa1f654564a5db57f5ef
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jul 12 11:18:47 2022 +0100

    libstdc++: Check for EOF if extraction avoids buffer overflow [PR106248]

    In r11-2581-g17abcc77341584 (for LWG 2499) I added overflow checks to
    the pre-C++20 operator>>(istream&, char*) overload.  Those checks can
    cause extraction to stop after filling the buffer, where previously it
    would have tried to extract another character and stopped at EOF. When
    that happens we no longer set eofbit in the stream state, which is
    consistent with the behaviour of the new C++20 overload, but is an
    observable and unexpected change in the C++17 behaviour. What makes it
    worse is that the behaviour change is dependent on optimization, because
    __builtin_object_size is used to detect the buffer size and that only
    works when optimizing.

    To avoid the unexpected and optimization-dependent change in behaviour,
    set eofbit manually if we stopped extracting because of the buffer size
    check, but had reached EOF anyway. If the stream's rdstate() != goodbit
    or width() is non-zero and smaller than the buffer, there's nothing to
    do. Otherwise, we filled the buffer and need to check for EOF, and maybe
    set eofbit.

    The new check is guarded by #ifdef __OPTIMIZE__ because otherwise
    __builtin_object_size is useless. There's no point compiling and
    emitting dead code that can't be eliminated because we're not
    optimizing.

    We could add extra checks that the next character in the buffer is not
    whitespace, to detect the case where we stopped early and prevented a
    buffer overflow that would have happened otherwise. That would allow us
    to assert or set badbit in the stream state when undefined behaviour was
    prevented. However, those extra checks would increase the size of the
    function, potentially reducing the likelihood of it being inlined, and
    so making the buffer size detection less reliable. It seems preferable
    to prevent UB and silently truncate, rather than miss the UB and allow
    the overflow to happen.

    libstdc++-v3/ChangeLog:

            PR libstdc++/106248
            * include/std/istream [C++17] (operator>>(istream&, char*)):
            Set eofbit if we stopped extracting at EOF.
            *
testsuite/27_io/basic_istream/extractors_character/char/pr106248.cc:
            New test.
            *
testsuite/27_io/basic_istream/extractors_character/wchar_t/pr106248.cc:
            New test.

    (cherry picked from commit 5ae74944af1de032d4a27fad4a2287bd3a2163fd)

  parent reply	other threads:[~2022-09-07 17:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11  1:39 [Bug libstdc++/106248] New: " Ting.Wang.SH at ibm dot com
2022-07-11  6:11 ` [Bug libstdc++/106248] " pinskia at gcc dot gnu.org
2022-07-11 11:07 ` redi at gcc dot gnu.org
2022-07-11 11:20 ` [Bug libstdc++/106248] [11/12/13 Regression] " redi at gcc dot gnu.org
2022-07-11 11:34 ` redi at gcc dot gnu.org
2022-07-11 11:36 ` redi at gcc dot gnu.org
2022-07-11 11:46 ` redi at gcc dot gnu.org
2022-07-11 12:38 ` redi at gcc dot gnu.org
2022-07-11 13:32 ` redi at gcc dot gnu.org
2022-07-12 22:40 ` cvs-commit at gcc dot gnu.org
2022-07-12 22:41 ` [Bug libstdc++/106248] [11/12 " redi at gcc dot gnu.org
2022-07-25 15:05 ` rguenth at gcc dot gnu.org
2022-08-03 13:47 ` cvs-commit at gcc dot gnu.org
2022-08-03 13:48 ` [Bug libstdc++/106248] [11 " redi at gcc dot gnu.org
2022-09-07 17:49 ` cvs-commit at gcc dot gnu.org [this message]
2022-09-07 17:53 ` redi at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-106248-4-7eZQDLSEBb@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).