Re: [RFC] libstdc++/9404 or weird stringbuf internals

[Paolo Carlini <pcarlini at unitus dot it>]

Benjamin Kosnik wrote:

> > Upon the first one, overflow is called since there isn't an
> > allocated string. Therefore overflow allocates one, then calls
> > sputc again, as prescribed by the standard (well, not really, in
> > fact it does *this->_M_out_cur = traits_type::to_char_type(__c);
> > which is not the same thing, but this is a minor nit which
> > could be easily fixed with some performance implications...).
> >    
> This should be fixed, and is an error in the current implementation.
>
> You can test this with a derived streambuf with a sputc member. I didn't
> do that, but it should probably be done.
Agreed, will do.

> As for the rest, it is an error with _M_out_end being set incorrectly.
> Petur's right, if epptr() == pptr(), overflow, but that should not be
> the case for the seconf sputc.
>
> // there is no condition in the standard that requires this.  
> // in fact, this should not be true.  
> assert(dsbuf.pub_epptr() == dsbuf.pub_pptr()); 
> // the standard says nothing about a mandated call to overflow here.
> called = false;
> dsbuf.sputc('a');
> assert(called);	// 20030212 fail
Well... What I still do not understand is this: at the end of  each 
sputc in a series (a series of single char appends, that is) which is a 
reasonable value for _M_out_end? Seems to me unescapable: _M_out_end == 
_M_out_cur.

Now, since for stringbuf, in my understanding at least, _M_out_end ==  
epptr() and _M_out_cur == pptr(), seems also unavoidable that overflow 
must be called by each sputc...

Should we perhaps decouple the internal _M_out_end and _M_out_cur from 
the epptr() and pptr() ???

Paolo.