« Bugzilla Issues Index
#2492 — 21.2.5.2.1 (RegExpExec): Access to [[RegExpMatcher]] in step 4 is visible by non-standard RegExp.p.compile
- bug_id:
2492
- creation_ts:
2014-02-03 05:25:00 -0800
- short_desc:
21.2.5.2.1 (RegExpExec): Access to [[RegExpMatcher]] in step 4 is visible by non-standard RegExp.p.compile
- delta_ts:
2014-04-06 11:29:51 -0700
- product:
Draft for 6th Edition
- component:
technical issue
- version:
Rev 22: January 20, 2014 Draft
- rep_platform:
All
- op_sys:
All
- bug_status:
RESOLVED
- resolution:
FIXED
- priority:
Normal
- bug_severity:
normal
- dependson:
1575
- everconfirmed:
true
- reporter:
André Bargull
- assigned_to:
Allen Wirfs-Brock
- commentid:
7171
- comment_count:
0
- who:
André Bargull
- bug_when:
2014-02-03 05:25:34 -0800
+++ This bug was initially created as a clone of Bug #1575 +++
The [[Match]] property was accessed in step 9 in ES5.1 (cf. 15.10.6.2 RegExp.prototype.exec), but has been changed to step 4 (cf. [[RegExpMatcher]] in RegExpExec abstract operation). This change is potentially user visible due to the non-standard RegExp.prototype.compile function.
Example:
---
var r = /a/;
r.lastIndex = {valueOf: function(){ print("compile"); r.compile("b","g") }}; r.exec("b")
---
V8 and Opera(12.15 - not V8 based) both return `["b"]`, whereas SpiderMonkey returns `null`. (JSC and IE10 don't even execute the valueOf function.)
Per the current ES6 draft, the expected result is `null`.
- commentid:
7276
- comment_count:
1
- who:
Allen Wirfs-Brock
- bug_when:
2014-02-12 16:51:03 -0800
fixed in rev23 editor's draft
The fix made for Bug #1575 was apparently revered, but I can't tell why. It may have been a crash recovery issue.
- commentid:
7534
- comment_count:
2
- who:
Allen Wirfs-Brock
- bug_when:
2014-04-06 11:29:51 -0700
fixed in rev23 draft