[RFC] libstdc++/8399

[Paolo Carlini <pcarlini at unitus dot it>]

Hi everyone,

this is a minimal testcase from the PR:

///////
#include <iostream>
using namespace std;

int main()
{
 ios::sync_with_stdio(false);

 char c;
 cin.get(c);

 return 0;

}
///////

Upon a <newline> the input doesn't terminate, as happens
without the 'sync'.

Basically this behaviour can be traced back to the call

 __elen = _M_file.xsgetn(reinterpret_cast<char*>(_M_in_beg),
                         _M_buf_size);

in basic_filebuf<char>::_M_underflow_common: when 'sync'
is false _M_buf_size is BUFSIZ, that is 8192 on x86-linux, and
since xsgetn is implemented as fread(__s, 1, __n, _M_cfile)
with __n == _M_buf_size, the observed behaviour is obtained.

If this behaviour is not correct, this seems a regression wrt
3.0.4: in that case the problem could not be present, since,
before Loren fix for libstdc++/2211, _M_buf_size was 1, even
when 'sync' was false.

Now, what can we do?

Is it correct, in general, to implement xsgetn in terms of fread?
In other terms, is this always equivalent, as prescribed by
the standard (27.5.2.4.3, 4), to a series of sbumpc()?

Or we should just avoid using xsgetn in _M_underflow_common?

Is there a way to do this without a performance regression
(see 2211)?

Or perhaps, when 2211 was fixed it was also known that we cannot
at the same time get 8399-type situations right?

Ciao for now, Paolo.