Why fixing 9533 doesn't fix 7744: revealed!

[Paolo Carlini]

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.