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

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

On Sat, Jun 07, 2003 at 12:41:12AM +0200, Paolo Carlini wrote:
> Paolo Carlini wrote:
> 
> >... however, I like even more the below, slightly simpler and which 
> >definitely keeps pbackfail working correctly (I will prepare a 
> >testcase for this, anyway). 
> 
> Actually, I believe a slight change is needed for pbackfail, in order to
> correctly return to the normal unbuffered situation after a sequence
> sgetc - putback.

This looks much better.  I haven't analyzed it in detail yet, but
nothing in here sets off alarm bells for me.

Some quibbles...

> +    _M_buf(NULL), _M_buf_size(BUFSIZ), _M_buf_allocated(false),

> +		    this->setg(NULL, NULL, NULL);

> +		this->setg(NULL, NULL, NULL);

We don't use NULL much in C++.  A literal 0 suffices.  I think the
next standard will introduce a distinguished value that may be
converted to any (but only a) pointer type, and it might be named
NULL.  Until then it only risks confusion, because if NULL is
accidentally passed to a function expecting (e.g.) an int, you get 
no warning, but the code looks like it's really passing a pointer.

> +		      this->setg(&_M_pback, &_M_pback, &_M_pback);
> +	      if (this->_M_in_end == &_M_pback)

I wonder if this code would be clearer if it used 1+&_M_pback:

> +		      this->setg(&_M_pback, 1+&_M_pback, 1+&_M_pback);

and compared _M_in_beg instead of _M_in_end.  In other words,
_M_pback is a one-character buffer, and the pointers treat it
that way.  For extra credit, maybe it should be a one-character
array; then:

+		      this->setg(_M_pback, 1+_M_pback, 1+_M_pback);
+	      if (this->_M_in_beg == _M_pback)

Or maybe I've been smoking crack again.

Nathan Myers
ncm-nospam@cantrip.org