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

[Jonathan Lennox <lennox at cs dot columbia dot edu>]

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

> Jonathan Lennox wrote:
> 
> >A potentially much simpler solution occured to me.  Could we declare that
> >Paolo's original patch (the one that started this thread) only applies to
> >cin?  I.e., make the condition this:
> >    if (__sbin == cin->rdbuf() && isatty(0))
> >
> >Would this work?  I'm not sure of all the potential details of reopening cin
> >-- is it possible for it to get disassociated from fd 0?
> >
> Hey Jonathan, during lunch time here in Italy the very *same* idea 
> occurred to me!
> 
> Let's investigate it (and its variants) further!

The trick is going to be to get it to work properly for both cin and wcin,
while not breaking things for any other type that a user decides to use to
instantiate a basic_streambuf.

Here's a suggestion.  Have a template function

  template<typename _CharT, typename _Traits>
  bool __streambuf_is_stdin_and_tty(const basic_streambuf<_CharT, _Traits>*)
  {
    return false;
  }

And then declare the specializations

  template<> bool __streambuf_is_stdin_and_tty<char, traits<char> >(const streambuf*);
  template<> bool __streambuf_is_stdin_and_tty<wchar_t, traits<wchar_t> >(const wstreambuf*);

These specializations can do the actual appropriate checks, as we've
described previously.  They can live in ios.cc, so they can safely compare
the passed-in buffer with [w]cin_buf and then access [w]cin_buf.fd() to call
isatty() on it; this is significantly cleaner than the other variants of
these tests, imo.

This would be an ABI change, though -- it would add two new exported symbols
to libstdc++.  What's the policy on this?  It wouldn't hurt old binaries
dynamically linking with new libstdc++, but the opposite wouldn't work.

I'm not crazy about the name of the function, but I can't think of anything
better off-hand.  Maybe a name which asked "is this a streambuf which should
be read a character at a time when copying it?" would be better, for future
extensibility if we find other streambufs for which that's true.

Note: I don't have a copyright assignment on file, so this is probably
getting involved enough that I shouldn't be the one to write the code.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu