Closed Bug 367388 Opened 14 years ago Closed 13 years ago
I can reproduce the bug under Ubuntu Linux and Windows XP. The bug only works for 'g' expressions. Here is a simple example: t = /abc/g; // g is important t.test("abc"); // true t.test("abcabc"); // true t.test("abcabc"); // false Maybe it is like this: The regex object remembers in g mode the position of the last result and starts it search there.
I used Firefox 184.108.40.206
I believe I have just come across the same bug with the following sample code: var re = new RegExp('([^asd])', 'g'); alert(re.test('t')); // returns true alert(re.test('t')); // returns false Granted, in the above example the 'g' is redundant but I find this unexpected behaviour highly undesirable. Surely the test method of the same RegExp object should always return the same result when provided with the same string? Using Firefox 220.127.116.11
This is all working as intended, if I understand the bug reports correctly. When a RegExp has the "g" flag, it doesn't reset the lastIndex value to zero when it starts a new match, so it starts from that position. It resets lastIndex to zero when it fails to match. (ECMAScript 3.ed. section 18.104.22.168, steps 3-6 and 10-11). RegExp literals create RegExp objects at parse time, so each literal corresponds to only one RegExp object, no matter how many times it's evaluated. (ECMAScript 3.ed. section 7.8.5)
The singleton RegExp object per literal is considered a bug in ES3 now, based on experience evident as testimony in bugzilla (this bug and many like it), and on the exceptional evaluation model (other "literals" in JS are evaluated each time to make a new object). Also, mutable objects should not be shared singletons when expressed literally, since the programmer can't tell where all the mutations occur in any program where references to the literal regexp escape. Programmers can make this hazard for themselves if they like even with a fixed regexp literal evaluation design, using global variables or shared heap references -- but the language should not do it by default. So, ECMA-262 Edition 3.1, which is available in draft form now (see http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft), fixes the design flaw in ES3 by making each evaluation of a regexp literal create a new RegExp instance. Technically, this bug report is a dup of bug 98409. We could morph it into a bug to track ES3.1, but I think it's better to mark it a dup. When we are close to having ES3.1 done (by next spring, probably sooner in the case at hand) we should file a new bug asking to track its change to regexp literal evaluation. Cc'ing sayrer -- Rob, do you know of a tracking bug for the 3.1 change (I didn't see one at a glance)? Please file one if needed. /be
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: regexpliteralflaw
(In reply to comment #6) > Cc'ing sayrer -- Rob, do you know of a tracking bug for the 3.1 change (I > didn't see one at a glance)? Please file one if needed. ES3.1 tracking: bug 445494.
No longer blocks: es5
You need to log in before you can comment on or make changes to this bug.