55587 - nsAReadableString::FindChar() should return index + offset

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P1)

Description

[Johnny Stenback (:jst)]

nsAReadableString::FindChar() is incorrectly returning the index of the
character it finds from the offset in stead of the index from the beginning of
the string. This patch fixes the problem:

Index: nsAReadableString.h
===================================================================
RCS file: /cvsroot/mozilla/xpcom/ds/nsAReadableString.h,v
retrieving revision 1.82
retrieving revision 1.82.12.1
diff -u -r1.82 -r1.82.12.1
--- nsAReadableString.h 2000/09/13 02:56:13     1.82
+++ nsAReadableString.h 2000/10/06 23:15:29     1.82.12.1
@@ -731,7 +731,7 @@
         PRInt32 fragmentLength = iter.size_forward();
         const CharT* charFoundAt = nsCharTraits<CharT>::find(iter.get(),
fragmentLength, aChar);
         if ( charFoundAt )
-          return lengthSearched + (charFoundAt-iter.get());
+          return lengthSearched + (charFoundAt-iter.get()) + aOffset;

         lengthSearched += fragmentLength;
         iter.advance(fragmentLength);

Comment 1

[Johnny Stenback (:jst)]

This bug causes infinite loops and incorrect construction of really long strings
that causes crashes and all kinds of nasty things. Nominating for rtm, this is a
blocker for bug 50742.

Comment 2

[Scott Collins]

sr=scc

Comment 3

[kinmoz]

r=[e-mail]

Note for PDT:

This bug will create *HUGE* strings, when saving HTML that contains a Text node 
with leading whitespace. So huge I ran out of memory on my 512Mb 
PC. I urge you to make this rtm++. :-)

This bug is present on the Trunk and Netscape_20000922_BRANCH.

Comment 4

[Scott Collins]

PDT: As the module owner for strings, I have marked this bug [rtm+] for your
consideration.

Comment 5

[Phil Peterson]

rtm++

Comment 6

[Johnny Stenback (:jst)]

Fixed on the trunk and branch.

Comment 7

[lchiang]

kin - can you help to see if this bug is now gone on the branch?  Thanks.

Comment 8

[kinmoz]

I just verified on Win32 that the bug no longer happens on the 
Netscape_20000922_BRANCH.