GCC Bugzilla Bug 38476

When compiled with gcc 4.3.1 the program below fails with SIGSEGV:

$ cat z.cpp && g++ z.cpp && ./a.out
#include <cassert>
#include <istream>
#include <streambuf>

int main ()
{
    static int x = '0';

    struct: std::streambuf {
        // unbuffered, always successfully reads one character
        int_type underflow () { return x++; }
    } sb;

    // "endless" stream that never reaches EOF
    std::istream endless (&sb);

    char s [4] = "";

    endless.read (s, sizeof s);

    // expect to extract as many characters as requested
    assert (endless.good ());
    assert (sizeof s == endless.gcount ());
    assert ('0' == s [0] && '1' == s [1] && '2' == s [2] && '3' == s [3]);
}
Segmentation fault

Hi. Given the specifications for uflow() (27.5.2.4.3/16), I don't see how this
code can work because I don't think *gptr() can work in this unbuffered case.
Can you explain in better detail what are you expecting?

To clarify: I don't see anything in the Standard forbidding the use of
rdbuf()->sgetn in the implementation of istream::read. Actually, I would argue
is the natural choice for carrying out the core work. Then, however, everything
bis equivalent per the Standard to a series of sbumpc and uflow (not underflow)
must be provided by the user.

Quoting [lib.istream], p2:

  Both [formatted and unformatted] input functions are described as if
  they obtain (or extract) input characters by calling rdbuf()->sbumpc()
  or rdbuf()->sgetc(). They may use other public members of istream.

sgetc() is required to return the result of underflow(), while sbumpc()
is required to return the result of uflow() (there's no requirement to
actually call either of these virtual functions, i.e., no Effects clause,
but that's a defect in the spec). The submitted test case assumes that
read() calls rdbuf()->sgetc() rather than sbumpc() which could be argued
makes it invalid.

An implementation of istream::read() may call streambuf::xsgetn() but it
must avoid calling an xsgetn() overridden in a derived class. Let me open
a separate issue for this.

Ok, let's close this one.