RE: libstdc++/9439: filebuf::sputbackc ignores beginning-of-file

["Pétur Runólfsson" <peturr02@ru.is>]

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

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: <paolo@gcc.gnu.org>,
	<bkoz@redhat.com>,
	<gcc-bugs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: RE: libstdc++/9439: filebuf::sputbackc ignores beginning-of-file
Date: Mon, 3 Feb 2003 13:56:12 -0000

 Hi,
 >     Hi. I don't think there is a bug here: I cannot find in the
 >     standard a specific prescription for the behaviour you
 >     expect (in particular in 27.5.2.4.4) Can you?
 
 Yes. 27.8.1.4 [lib.filebuf.virtuals] p5 describes how pbackfail may
 put back the character c. The only cases that can apply here are the
 ones starting with
 
   If traits::eq_int_type( c ,traits::eof()) returns false and if the
   function makes a putback position available
 
 The meaning of "a putback position available" is defined in
 27.5.1 [lib.streambuf.reqts] p3
 
   If xnext is not a null pointer and xbeg < xnext for an input
   sequence, then a putback position is available
 
 and 27.5.1 [lib.streambuf.reqts] p2 states that xbeg points to the
 beginning of an array that
 
   represents, [...], a (sub)sequence of characters from the sequence
 
 Finally, "the sequence" is defined in 27.8.1.1 [lib.filebuf] p1
 
   The class basic_filebuf<charT,traits> associates both the input
   sequence and the output sequence with a file.
 
 >     Indeed, sputbackc calls, as expected, pbackfail, which in=20
 > turns calls seekoff (fstream.tcc, line 218) (pay attention
 >     to the preceding comment which means that this specific=20
 > situation was considered and _not_ supposed to lead to an
 >     obvious failure).
 
 I read "at the beginning of the buffer" as simply meaning that
 gptr() =3D=3D eback(), not as "at the beginning of the file".
 
 > The latter call then does _not_ fail and
 >     a put back buffer is created by _M_pback_create(), hosting
 >     the put back char, _exactly as happens_ when __testpb &&
 >     !__testeof && !__testeq, above.=20
 >     I agree that a few widespread implementations behave
 >     differently in this case, but we are, I maintain, in the
 >     realm of implementation defined behaviour.
 >    =20
 >     Paolo.
 >=20
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&
 database=3Dgcc&pr=3D9439
 
 Petur