This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, Feb 13, 2003 at 11:34:08AM +0100, Paolo Carlini wrote:
> 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() ???

The buffer used by stringbuf should grow in exactly the same way that
it grows in basic_string (probably using the same function).  The 
end pointer should always point at the last (but one) place in the
actual string buffer.  There should never be any confusion about where
the string ends, where the put position is, and where the buffer ends, 
they're three separate values.  If the put position (pptr()) goes 
beyond the length of the string, that can be patched up in str().  
(Don't forget to poke a NUL in, then, too.  (Grrr.))

Nathan Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]