On Sun, 9 Dec 2001, Matthias Klose wrote: > I should not patch libstdc++ myself :-( This is the offending patch, > introduced to resolve a "severe performance problem" compared to > gcc-2.95.2. See #92524 and #100571. > http://bugs.debian.org/92524 > http://bugs.debian.org/100571 > > --- src-native/libstdc++/sstream~ Tue Dec 5 06:32:17 2000 > +++ src-native/libstdc++/sstream Tue Jun 26 07:11:03 2001 > @@ -106,7 +106,7 @@ > if (c != EOF) > { > streamsize old_stream_len = stream_len; > - stream_len += 1; > + stream_len += stream_len + 1;
Yeah, I can see how this would cause the problems given in 109073. The original line above seems to increase the stream_len buffer one char at a time, as the submitter noted in #92524, but while the new above line would increase the length faster, if those bytes aren't filled, you'll probably end up with extra (random) chars at the end of whatever is supposed to be in the buffer. I don't see a nicer/speedier way of doing this without going to something like what libstdc++-v3 does (which uses pointer math and is probably much faster). See strstream.cc:458 in the libstdc++-v3 sources for an example of that. > So the safest thing would be to revert the patch. Could somebody have > a look for a correct fix? The testcase provided in #109073 and #115978 > fails with this patch. > http://bugs.debian.org/109073 > http://bugs.debian.org/115978 Reverting is safe, although it won't help the performance woes of the prior reports. The big question is, is it really helping to rewrite the code? If you revert, the code will work as expected, albeit slowly in some cases. If you rewrite it, it may speed it up, but won't get the needed testing to debug it properly for probably quite some time. You could also appeal to upstream to make the old code behave and look more like the new code :-P C