From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 747F23856DF7; Fri, 13 May 2022 20:52:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 747F23856DF7 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag Date: Fri, 13 May 2022 20:52:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component short_desc cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 20:52:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105580 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c++ |libstdc++ Summary|[12/13 Regression] False |[12/13 Regression] warning |warning "potential null |"potential null pointer |pointer dereference" raised |dereference" raised when |when using |using istreambuf_iterator |istreambuf_iterator and any |and any "-O" flag |"-O" flag | CC| |jason at gcc dot gnu.org --- Comment #1 from Jason Merrill --- The theory of the warning seems to be that if istreambuf_iterator::_M_get, called from operator* for *__beg in _M_construct, hits EOF, it clears _M_sb= uf, and then ++__beg will try to refer to members of the now-null __beg._M_sbuf= .=20 At first glance, this seems like a plausible theory. Why does _M_get clear _M_sbuf? int_type _M_get() const { int_type __ret =3D _M_c; if (_M_sbuf && _S_is_eof(__ret) && _S_is_eof(__ret =3D _M_sbuf->sge= tc())) _M_sbuf =3D 0; return __ret; }=