[Patch] Fix seek to beg after grow bug

Paolo Carlini pcarlini@unitus.it
Tue Feb 18 21:31:00 GMT 2003


Nathan Myers wrote:

>This doesn't seem quite right.  I think the right code is
>more like just
>
>      __size_type __len = std::max(_M_string.size(),
>        __size_type(this->_M_out_cur - this->_M_out_beg));
>
>In other words, either cur and beg are both 0, or (cur - beg) is 
>at least as large as the string.
>
No, this cannot be ok.
Look at the testcase: _M_out_cur == _M_out_beg in that case and _M_out_end,
which points one-past-end, gives the current string length, as _M_out_end -
_M_out_cur which is _bigger_ than _M_string.size().
Indeed, the code continues as:

    return __string_type(this->_M_out_beg, this->_M_out_beg + __len);

>We have to be sure, too, that in seek{pos,off}, the string length gets 
>updated like the above before _M_out_cur gets moved, because sometimes 
>_M_out_cur is our only record of how long the string really has become.
>
Humm. The seeks do not change any lenght by themselves, but they change 
_M_out_cur,
but _always_ via _M_out_cur_move which is:

       _M_out_cur_move(off_type __n) // argument needs to be +-
       {
         bool __testin = _M_in_cur;

         _M_out_cur += __n;
         if (__testin && _M_buf_unified)
           _M_in_cur += __n;
         if (_M_out_cur > _M_out_end)
           {
             _M_out_end = _M_out_cur;
             // NB: in | out buffers drag the _M_in_end pointer along...
             if (__testin)
               _M_in_end += __n;
           }
        }

Therefore, you can see that _M_out_cur _cannot_ become bigger than 
_M_out_end.

Really, it seems to me that _M_out_end is _always_ equal to the string end,
and in fact, as such is used (under the name epptr, but this is another 
story :)
in the seek operation which we already privately discussed about...

>Likewise, whenever the buffer gets lengthened, the string capacity 
>needs to be updated along with _M_out_end.
>
This is done correctly, if not with optimal efficiency by str(), it seems.

Do you agree??

Paolo.



More information about the Libstdc++ mailing list