[v3] Fix second half of libstdc++/6745

[Jonathan Lennox]

On Monday, November 18 2002, "Paolo Carlini" wrote to "Jonathan Lennox, gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org" saying:

> Jonathan Lennox wrote:

> >One problem with this.  __copy_streambufs is a general function -- it's not
> >just used to copy from stdin.  However, this patch conditionalizes the
> >function's buffer size on isatty(0), even though in many cases when it's
> >used, (i.e., copying from a readable buffer other than cin->rdbuf()), the
> >nature of stdin is irrelevant.
> >
> Hummm...
> Could you possibly post an example accompanying your argument (which is 
> probably correct!)? I'd like to see some code which incorrectly leads to 
> 1 whereas BUFSIZ would be perfectly ok (and faster!).

I'm pretty sure it can't happen with any of the standard streambuf classes
defined by the C++ standard, but it can easily happen for user-defined
streambuf classes.

As an example, consider test_buffer_1 from
libstdc++/testsuite/27_io/ostream_inserter_other.cc:
  class test_buffer_1 : public std::streambuf 
  {
  public:
    test_buffer_1(const std::string& s) : str(s), it(str.begin()) { }
  
  protected:
    virtual int underflow() { return (it != str.end() ? *it : EOF); }
    virtual int uflow() { return (it != str.end() ? *it++ : EOF); }

  private:
    const std::string str;
    std::string::const_iterator it;
  };

__copy_streambufs will loop once without your patch, but s.length() times
with it, if stdin is a tty.

An actual practical example is something like Matt Austern's syncstream,
which is attached to PR 8071.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu