From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31175 invoked by alias); 3 Feb 2003 14:06:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 31159 invoked by uid 71); 3 Feb 2003 14:06:00 -0000 Date: Mon, 03 Feb 2003 14:06:00 -0000 Message-ID: <20030203140600.31158.qmail@sources.redhat.com> To: paolo@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= Subject: RE: libstdc++/9439: filebuf::sputbackc ignores beginning-of-file Reply-To: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= X-SW-Source: 2003-02/txt/msg00101.txt.bz2 List-Id: The following reply was made to PR libstdc++/9439; it has been noted by GNATS. From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= To: , , , , 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 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