RE: libstdc++/9424: i/ostream::operator>>/<<(streambuf*) drops characters

[Pétur Runólfsson <peturr02 at ru dot is>]

The following reply was made to PR libstdc++/9424; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02 at ru dot is>
To: <paolo at gcc dot gnu dot org>,
	<bkoz at redhat dot com>,
	<gcc-bugs at gcc dot gnu dot org>,
	<ncm at cantrip dot org>,
	<nobody at gcc dot gnu dot org>,
	=?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02 at ru dot is>,
	<gcc-gnats at gcc dot gnu dot org>
Cc:  
Subject: RE: libstdc++/9424: i/ostream::operator>>/<<(streambuf*) drops characters
Date: Wed, 26 Feb 2003 09:27:32 -0000

 >     The issue is the following: when a setg(buf, buf, buf + 10)
 >     is missing, __copy_streambufs, called by operator>>, ends up
 >     using sgetn to fill an internal temporary buffer.
 >    =20
 >     The latter, in turn, calls unavoidably the custom uflow,
 >     which moves 'current' past the end of the buffer, and=20
 >     underflow, called by sgetc, does not return the expected
 >     '1'.
 >    =20
 >     Now, everything boild down to the following general=20
 >     question: is an implementation of operator>> allowed to
 >     call (indirectly) sgetn?
 
 I believe the relevant quote is in 27.6.2.5.3 p7, bullet 2:
 
   inserting in the output sequence fails (in which case the
   character to be inserted is not extracted);
 
 So correct code is "as if":
 
 int_type c =3D sbin->sgetc();
 while (c !=3D traits_type::eof())
 {
   if (sbout->sputc(c) =3D=3D traits_type::eof())
     break;
   c =3D sbin->snextc();
 }
 
 Of course, it should be OK to call sgetn if the function *knows*
 that sputc won't fail (for example if epptr() - pptr() is big
 enough).
 
 Petur