🚀 go-pugleaf

The iostream classes in libg++ 2.0 have a bug in them when reading an EOF,
as illustrated by this program:

#include <iostream.h>
main()
{
  char buf[100];
  int i = 0;
  while( cin >> buf )
    cout << i++;
}

The program will happily read in input until EOF, then read another string,
then exit.  This is due to this chain of operation:

operator>>(istream,char*) calls istream::ipfx0()
istream::ipfx0() calls ws(istream&)
ws(istream&) calls streambuf::sbumpc()
sbumpc() calls underflow()
underflow() calls ::read()

at this point, underflow realizes that we're at EOF and sets a flag to that
effect.  So it returns EOF to ws.

ws sets ios::eofbit for cin, and returns.
ipfx0() returns happily to operator>>

operator>> calls sbumpc()
sbumpc() calls underflow()
underflow() calls ::read()
read() returns the string after the EOF
underflow() returns
sbumpc() returns the first character after the EOF
etc.

I'm not sure where the problem should be fixed.  Should ipfx0() return 1 if
the stream is at EOF?  Should sbumpc check ios::eofbit?  Or should
underflow() check its own flag?

I decided that underflow() should be responsible.  Does anyone disagree?

*** /staff/jason/oldfilebuf.C	Sat Mar 28 12:34:34 1992
--- /gnu/libg++-2.0/libg++/iostream/filebuf.C	Sat Mar 28 02:17:58 1992
***************
*** 269,274
  	return (EOF);
  #endif
  
      if ((xflags() & _S_CAN_READ) == 0) // SET ERROR
  	return EOF;
    retry:

--- 269,276 -----
  	return (EOF);
  #endif
  
+     if (xflags() & _S_EOF_SEEN) return EOF;
+ 
      if ((xflags() & _S_CAN_READ) == 0) // SET ERROR
  	return EOF;
    retry:

--
Jason Merrill
jason@jarthur.claremont.edu