[Patch] Fix libstdc++/9404 (and all that)

[Paolo Carlini]

Hi!

Finally, here it is. I have incorporated Nathan's rewrote of
stringbuf::overflow and implemented his suggestion to let the
string grow according to his builtin exponential policy: the
first time that overflow is called the new capacity is
max(capacity + 1, _M_buf_size_opt), then we let the string grow
exponentially on its own, by requesting, essentially,
reserve(capacity + 1). This change led to some further improvements
wrt my previous post (in particular, now _M_buf_size is now unused
for stringbuf, since the information is readily available as
_M_string.capacity).

In a nutshell, I think we have implemented the bulk of Nathan's
outline explained here, for example:

    http://gcc.gnu.org/ml/libstdc++/2003-02/msg00282.html

The TODO list includes:
1- Fixing the broken strstreams (this point makes me _really_ nervous).
2- Performance work (now that correctness is achieved ;)
3- Further clean-ups (_M_set_*determinate?, checks having dubious end
   limits)

I have tested the below (which now includes both filebuf and stringbuf
testcases), with reduced _M_buf_size_opt too in order to exercise more
heavily the overflow/reallocation scenarios: from 8192 to 16 for filebuf,
and from 512 to 4 for stringbuf. Everything on x86-linux, as usual.

Shall we put this in?

Thank,
Paolo.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_9404
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030223/c18f52e9/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_9404_30
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030223/c18f52e9/attachment-0001.ksh>