Bug 11231 – RegExp bug when handling newline characters

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Brad Choate]

Test case:

        var s1 = "\nAbc\n";
        var s2 = s1.replace(/(\n)[^\n]+$/, '$1');
        if (s1 == s2)
            alert("expected: s1 == s2");
        else
            alert('s1 != s2: "' + s2.replace(/\n/g,"\\n") + '" != "\\nAbc\\n"');

In FireFox, IE and Perl, s1 == s2. In Safari (even in the latest nightly builds), s2 is stripped of the inner 'Abc' characters.

Changing the regex to use * instead of + doesn't change the result either.

[David Kilzer (:ddkilzer)]

Created attachment 17031 [details]
Test case from Comment #0

[Darin Adler]

What's broken here is the $ operator. It's matching a newline at the end of the string. I have a fix.

[Darin Adler]

Created attachment 17216 [details]
patch for this and a few other problems

[Geoffrey Garen]

Comment on attachment 17216 [details]
patch for this and a few other problems

r=me

[Darin Adler]

Committed revision 27752.

[Eric Seidel (no email)]

I take it this was no change for sunspider?

[Darin Adler]

(In reply to comment #6)
> I take it this was no change for sunspider?

I'm not sure. I'll test now.

[Darin Adler]

SunSpider claims this slowed things down almost 1%. But what is so crazy is that the effects were mostly on the tests that don't use regular expressions at all!

For example, it says partial-sums is 2% slower. But there's not a single call into the regular expression for partial-sums.

Similarly, it claims that string-base64 is 2% slower. Also doesn't use regular expressions at all.

Claims that string-fasta is 2.6% slower. Also doesn't use regular expressions at all.

It says regexp-dna is 0.6% faster. That one uses regular expressions.

This patch is entirely about correctness, not performance, and it should make regular expressions slightly *faster*. I have no idea why SunSpider thinks it makes non-regular-expression tests slower.

We may need to fix SunSpider.