Unexpected SyntaxError for /^{(.*)\}$/

RESOLVED FIXED in 1.5R5

Status

Rhino
Core
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: Igor Bukanov, Assigned: rogerl (gone))

Tracking

other
1.5R5
x86
Linux

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Rhino  2003-01-25 CVS

Already applied fix for the bug 189898 broke js1_2/Objects/toString-001.js test
case which now fails with:

*-* Testcase js1_2/Objects/toString-001.js failed:
Expected exit code 0, got 3
Testcase terminated with signal 0
Complete testcase output was:
js: uncaught JavaScript exception: SyntaxError: Invalid quantifier {


The test case fails when it declares the following regular expression:

/^{(.*)\}$/



Reproducible: Always

Steps to Reproduce:
1. Run Rhino shell
2. Enter there the foolowing regular expression:
/{\}/
Actual Results:  
js: uncaught JavaScript exception: SyntaxError: Invalid quantifier {


Expected Results:  
/{\}/
(Reporter)

Comment 1

15 years ago
Reassign to Roger
Assignee: nboyd → rogerl
(Reporter)

Comment 2

15 years ago
Although the Ecma standard does not allow standalong {, but SM and js in MSIE
allows it.
(Assignee)

Comment 3

15 years ago
Sigh. Once the mega-fix for 85721 goes in, SM will fail on this, too. ECMA
clearly disallows this, but backwards and MSIE compatibility arguments are stronger.

Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

15 years ago
OK, double-sigh. Now regress-188206 will fail because we explicitly included '{'
as a bad thing resulting from that bug report (bug 188206). Looking for
suggestions, back out this fix and stay with ECMA, or officially support '{' and
change the test ?

Comment 5

15 years ago
FWIW:

The test js1_2/Objects/toString-001.js uses the regexp in question
to check the output of the Object.prototype.toString() function.

Such output is expected to begin and end with a curly bracket.
This is the regexp the test uses to check for that:

function checkObjectToString(s, a) {
  var m = /^{(.*)\}$/(s);
  if (!m)
    return false;  // should begin and end with curly brackets

         etc.
         etc.


Notice that the right brace was escaped, but the left one not.
It looks simply like an oversight when the test was written.

As Roger indicates, the ECMA-262 Edition 3 Final spec is quite clear
that neither '{' nor '}' may appear in a regexp literal unescaped.


However, note that Perl seems to allow '{' and '}' to appear unescaped.
Note, I'm switching between 'p' and 'P' as a sanity check:

perl -e 'if ("{p:1}" =~ /{p/) {print("MATCH!");} else {print("NO MATCH");}'
MATCH!
perl -e 'if ("{p:1}" =~ /{P/) {print("MATCH!");} else {print("NO MATCH");}'
NO MATCH

perl -e 'if ("{p:1}" =~ /{p:1}/) {print("MATCH!");} else {print("NO MATCH");}'
MATCH!
perl -e 'if ("{p:1}" =~ /{P:1}/) {print("MATCH!");} else {print("NO MATCH");}'
NO MATCH


Now, let's try the specific regexp above:
$ perl -e 'if ("{p:1}" =~ /^{(.*)\}$/) {print("MATCH!");}'
MATCH!

Here, without the escape of '}':
$ perl -e 'if ("{p:1}" =~ /^{(.*)}$/) {print("MATCH!");}'
MATCH!



Furthermore, all three of these browsers currently allow it:
Moz/N6/N7, IE6, and N4.7. I will attach an HTML testcase below.

Note we had a similar situation in bug 141078,
"Should JS support octal escape sequences in regexps?"

Here was Brendan's take on that issue: bug 141078 comment 2.

Comment 6

15 years ago
Created attachment 112826 [details]
HTML testcase

Comment 7

15 years ago
In any case, I've gone ahead and added the missing escape to the testcase.
Even though it's "historic" (i.e. lies in the js1_2 directory), I couldn't
find any deliberate reason via bonsai for having the right brace escaped
but the left one not:

http://bonsai.mozilla.org/cvslog.cgi?
file=mozilla/js/tests/js1_2/Objects/toString-001.js

Comment 8

15 years ago
I have modified mozilla/js/tests/ecma_3/RegExp/regress-188206.js
to follow Perl custom regarding braces in regexp patterns.

For reference, from the "perlre" doc on the Web:

----
The following standard quantifiers are recognized:

   *      Match 0 or more times
   +      Match 1 or more times
   ?      Match 1 or 0 times
   {n}    Match exactly n times
   {n,}   Match at least n times
   {n,m}  Match at least n but not more than m times

If a curly bracket occurs in any other context, it is treated
as a regular character.
----


The testcase now tests that braces may appear unescaped in regexp
patterns, even they are not part of a quantifier. This will enforce 
backward compatibility, and compatibility with IE.

Comment 9

15 years ago
Created attachment 113066 [details]
HTML testcase #2  (for Moz and IE only; NN4.x won't accept try...catch)

Comment 10

15 years ago
Have to reopen this bug. With the new sections, testcase
ecma_3/RegExp/regress-188206.js is failing in Rhino.

These sections use braces, unescaped, as literal characters
in regexp patterns. Even though this is ECMA-incorrect, we
expect no errors, re the compatibility issues raised above -
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 11

15 years ago
Fixed in patch for bug 85721
Depends on: 85721

Comment 12

15 years ago
Confirming - with the latest patch for bug 85721, the testcase

      mozilla/js/tests/ecma_3/RegExp/regress-188206.js

passes in SpiderMonkey; still failing in Rhino.

Comment 13

15 years ago
Created attachment 128343 [details] [diff] [review]
Cleaned up weird quantifier handling

Comment 14

14 years ago
Fixed in bug 225926
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED

Comment 15

14 years ago
Trageting as resolved against 1.5R5
Target Milestone: --- → 1.5R5
You need to log in before you can comment on or make changes to this bug.