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

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

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 
> turns calls seekoff (fstream.tcc, line 218) (pay attention
>     to the preceding comment which means that this specific 
> 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() == 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. 
>     I agree that a few widespread implementations behave
>     differently in this case, but we are, I maintain, in the
>     realm of implementation defined behaviour.
>     
>     Paolo.
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&;
database=gcc&pr=9439

Petur