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)
next prev 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: linkBe 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).