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

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.

Thanks Nathan.

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)


(*) 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.

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