Re: Why fixing 9533 doesn't fix 7744: revealed!

[Paolo Carlini <pcarlini at unitus dot it>]

Hi,

Nathan Myers wrote:

> OK, syncing with stdio is a special case.  I am not surprised to see 
> in_avail() call showmanyc() for that case, nor to find it reporting 0.  
> The _M_set_indeterminate() call is necessary so that the next sgetc()
> will call underflow(), and get the character out of stdin's putback
> cell.  It is necessary to have _M_buf_size == 1 when synced with stdio.
Ok, thanks for the explanation.

> If the program began with "std::ios::sync_with_stdio(false);" I would hope 
> for different behavior.  In other words, 7744 is "not a bug" without a 
> call to std::ios::sync_with_stdio(false).  However, I find that even when 
> it has been called, in_avail() still returns zero on cin.  That's the bug.
> When that call occurs before any input, then you would like to have a 
> normal big buffer, so the next underflow will fill it as much as it can.
Ok, let's try to fix this, then. I'm afraid this is the upshot of a recent
commit of mine (and Loren's). There is this code in src/ios.cc

   size_t __in_size =
     (__sync || isatty (0)) ? 1 : static_cast<size_t>(BUFSIZ);

We introduced that isatty(0) in order to fix an _interactive_ bug, that is
libstdc++/8399:

   http://gcc.gnu.org/ml/libstdc++/2002-11/msg00096.html

Basically, this kind of testcase:

#include <iostream>
using namespace std;

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

char c;
cin.get(c);

return 0;
}

didn't terminate upon newline. I thought, at the time, that the problem
could not be avoided in other ways, since (citing myself ;):

> 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.

Nathan, fellow v3 contributors, what can be do to have a big buffer
without breaking 8399-type interactive code?

Thanks in advance,
Paolo.