Is this user-code working in a glibc (or Solaris) environment?

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In order to help test v3, I am attempting to recompile some C++ code
bases that works fine on libstdc++-v2 (and Sun C++ 5).  The code was
written to be fairly non-demanding of the standard library (other than
the classic STL part) to aid portability and thus compiles without any
changes.  However, apparently, there is one common idiom I use that
appears to be broken in my environment under some usage cases.  This
short program displays the problem I am seeing with v3 in my non-glibc
environment, i686-unknown-freebsdelf3.4 (all-but-1 test cases pass,
the only failure is completely unrelated):

#include <string>
#include <iostream>

int
main (int argc, char* argv[])
{
  std::string s;

  while (std::cin >> s)
    std::cout << s << std::endl;

  return 0;
}

[Sorry about the form of this report and testcase, but the incorrect
 behavior depends on it being a pipe attached to std::cin.]

; /usr/local/bin/g++ st.C # 2.95.3 with libstdc++-v2
; (echo 'abc def';echo '123')|a.out
abc
def
123
; (echo 'abc def';sleep 1;echo '123')|a.out
abc
def
[one-second pause]
123
; (echo 'abc def';echo '123') >/tmp/zzzzzz;a.out </tmp/zzzzzz
abc
def
123

; /usr/local/beta-gcc/bin/g++ st.C # mainline with libstdc++-v3
; (echo 'abc def';echo '123')|a.out
a
; (echo 'abc def';sleep 1;echo '123')|a.out
[one-second pause]
a1
; (echo 'abc def';echo '123') >/tmp/zzzzzz;a.out </tmp/zzzzzz
abc
def
123

I have attempted to debug this smaller test case for some time last
night without any real success.  I admit that I don't entirely
understand all the code in std::__basic_file::seekoff()
[c++io.cc:210].  In particular, the first time through it jumps to the
'dumb:' label and proceeds to reset this->_IO_read_ptr (which would
appear to trash the state of the read buffer which is attached to a
non-rereadable descriptor attached to stdin).  Then, during a later
time through, it actually tries to read() again from the descriptor,
as if that is the correct mechanism to recover data from a
non-rereadable descriptor.

Regards,
Loren