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

[Paolo Carlini]

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.