[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
I've implemented the suggested changes to istreamubf_iterator and also proposed
them as a resolution for LWG 2366 https://wg21.link/lwg2366

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-03-31

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #1)
> Why does _M_get clear _M_sbuf?

Because that's what the standard implies should happen:

  If the end of stream is reached (streambuf_type::sgetc() returns
traits::eof()),
  the iterator becomes equal to the end-of-stream iterator value."

  charT operator*() const;
  1 Returns: The character obtained via the streambuf member sbuf_->sgetc().


But this means that a dereferenceable iterator can become non-dereferenceable
as a result of dereferencing it ... which seems very wrong indeed.

It seems better to check for EOF on operator++ and only clear _M_sbuf in that
function, but we need to basically rewrite the entire class (without ABI
changes) to do that.

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.2|12.3

--- Comment #3 from Richard Biener  ---
GCC 12.2 is being released, retargeting bugs to GCC 12.3.

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Might be due to the changes in r253417

[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

[jason at gcc dot gnu.org via Gcc-bugs]

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

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_sbuf,
and then ++__beg will try to refer to members of the now-null __beg._M_sbuf. 
At first glance, this seems like a plausible theory.  Why does _M_get clear
_M_sbuf?

  int_type
  _M_get() const
  {
int_type __ret = _M_c;
if (_M_sbuf && _S_is_eof(__ret) && _S_is_eof(__ret = _M_sbuf->sgetc()))
  _M_sbuf = 0;
return __ret;
  }