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 Fri, Feb 14, 2003 at 05:29:20PM +0100, Paolo Carlini wrote:
> Nathan Myers wrote:
> >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.
> Indeed, I believe that probably some bugs (e.g., 9404!) may stem from a 
> confusion of this sort!
> This means that we must keep track separately of the end of the string, 
> which, if I understand
> what you are saying, is _not_ pptr(), nor epptr() but a _different_ 
> thing, roughly pbase + size() (*)!


> But currently we do _not_ do so! We do _not_ really have a variable 
> storing unambiguously the string end! Often we try to synthesize the 
> string end from pptr and/or epptr! (just look at the current
> seekpos in sstream.tcc)

Yes, the current code is written to the (erroneous) normative
text, where the actual string length actually could be deduced 
from the pptr() position, because they were never allowed to
stray.  Now that we have resolution 169, we are authorized to 
let pptr() wander beyond the end of the string out to the string
capacity, and we only need to sync them up again when somebody 
looks at the resulting basic_string<> object.

> (*) All of this complicated by the fact that the string object is not 
> accessed as a 'real' string object, but by way of pointer operations 
> and, after the creation, size() does _not_ return anymore the actual
> size of the string, which would give, added to pbase, the string end 
> which we are talking about.
Sigh.  Looking at stringbuf<>::str(), it seems to be doing almost the 
right thing, already about computing the new string length.  (It should
use _M_out_cur instead of _M_out_end in argument to max.)  However,
instead of just poking the new length in the representation, it 
allocates a whole new string.  Bad.  I think it should change _M_out_cur
afterward so that overflow will be called if any further changes are
attempted.  Overflow should clone the string if necessary, and
then put _M_out_cur back to the right place.  In many cases the
stringbuf is discarded after str(), or the result of str() is 
discarded, and the clone never has to happen.

Nathan Myers

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