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

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Wed, Mar 05, 2003 at 09:19:44PM +0100, Paolo Carlini wrote:
> Nathan Myers wrote:
> >If the program began with "std::ios::sync_with_stdio(false);" 
> >... 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

I remember that going by, and it bothered me deeply at the time,
but I didn't understand well enough what you were doing to have 
anything constructive to suggest.

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

The call to xsgetn is at the wrong level of abstraction.  It keeps
trying until it gets n characters, or EOF.  You want to call ::read()
in underflow(), and just go with as many characters as it returns.
(If it returns -1 and errno is EINTR you would call it again.)
Then, get rid of that isatty()!

Nathan Myers
ncm-nospam at cantrip dot org