Bug 105580 - [12/13/14/15 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
Summary: [12/13/14/15 Regression] warning "potential null pointer dereference" raised ...
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 12.0
: P2 normal
Target Milestone: 12.5
Assignee: Jonathan Wakely
URL:
Keywords: diagnostic
: 112421 115067 (view as bug list)
Depends on:
Blocks: Wnull-dereference
  Show dependency treegraph
 
Reported: 2022-05-12 09:41 UTC by Jonathan Gaffiot
Modified: 2024-06-20 09:05 UTC (History)
12 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-03-31 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Gaffiot 2022-05-12 09:41:41 UTC
I found what I believe is a false positive with g++ 12 when using the "null-dereference" warning and istreambuf_iterator with any level of optimisation. And of course the "-Werror" flag is mandatory in my company process.
I have searched for such similar bug report.

This behavior does not show up with g++ 11.2.0 or g++ 9.4.0.

Minimal example (basically the first lines of the cppreference example for istreambuf_iterator):

#include <string>
#include <sstream>

int main()
{
    std::istringstream in{"Hello, world"};
    std::istreambuf_iterator<char> it(in), end;
    std::string ss{it, end};
    return 0;
}

Compiled with:
g++-12 -O -Wnull-dereference <my_file>

Compiler version (default g++-12 on Ubuntu 22.04):
g++ (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]



Full version:
Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12-20220319-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f] (Ubuntu 12-20220319-1ubuntu1)
Comment 1 Jason Merrill 2022-05-13 20:52:08 UTC
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;
      }
Comment 2 Jonathan Wakely 2022-05-13 21:12:08 UTC
Might be due to the changes in r253417
Comment 3 Richard Biener 2022-08-19 08:26:22 UTC
GCC 12.2 is being released, retargeting bugs to GCC 12.3.
Comment 4 Jonathan Wakely 2023-03-31 15:08:01 UTC
(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.
Comment 5 Jonathan Wakely 2023-04-12 15:43:03 UTC
I've implemented the suggested changes to istreamubf_iterator and also proposed them as a resolution for LWG 2366 https://wg21.link/lwg2366
Comment 6 Richard Biener 2023-05-08 12:24:26 UTC
GCC 12.3 is being released, retargeting bugs to GCC 12.4.
Comment 7 Jonathan Wakely 2023-11-07 11:38:31 UTC
*** Bug 112421 has been marked as a duplicate of this bug. ***
Comment 8 Jonathan Wakely 2024-05-13 11:11:23 UTC
*** Bug 115067 has been marked as a duplicate of this bug. ***
Comment 9 Richard Biener 2024-06-20 09:05:01 UTC
GCC 12.4 is being released, retargeting bugs to GCC 12.5.