Re: [RFC/Patch] What about using seekoff(-1, ...) for unbuffered underflow?

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Fri, Jun 06, 2003 at 02:22:04PM +0200, Paolo Carlini wrote:
> I'm looking a bit into the new framework for unbuffered input,
> and I'd rather prefer having sbumpc() simple as it was before.
> 
> Also, keeping _M_buf_size in basic_filebuf only.

The changes removing _M_buf_size from streambuf look excellent,
necessary, and long overdue.  If _M_buf_size is to be a member, 
filebuf is the right place for it.   (This is not just opinion: 
building knowledge of streambuf implementation details into filebuf 
breaks streambuf specializations permitted by the standard.)

*However*, the change in filebuf to do a seek per character can't be 
right.  You aren't guaranteed a seek will ever succeed, except on 
certain file-descriptor types.

> @@ -283,10 +283,7 @@
>  		  // it calls underflow... which leads to a recursive
>  		  // showdown.
>  		  if (!__bump)
> -		    {
> -		      _M_create_pback();
> -		      *this->_M_in_cur = traits_type::to_char_type(__ret); 
> -		    }
> +		    _M_file.seekoff(-1, ios_base::cur, ios_base::in);

On an unbuffered stream, the gptr() and pptr() values never need to be 
non-null, so there's no need for code in any streambuf member to know
about the unbuffered condition.  It can all be handled in the virtuals.

I.e. you can have a putback area in the filebuf, but *not* point the 
streambuf's pointers at it.  Alternatively, gptr() can be set to point 
after the putback cell, and equal to egptr(), if that makes for simpler 
logic in the filebuf virtuals.

Nathan Myers
ncm@cantrip.org