The default bug view has changed. See this FAQ.

Cannot set arguments[n] under certain circumstances

VERIFIED FIXED in mozilla1.8beta4

Status

()

Core
JavaScript Engine
P3
normal
VERIFIED FIXED
12 years ago
11 years ago

People

(Reporter: Erik Fabert, Assigned: brendan)

Tracking

({js1.5, testcase, verified1.8})

Trunk
mozilla1.8beta4
js1.5, testcase, verified1.8
Points:
---
Bug Flags:
blocking1.8b5 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
arguments[n] cannot be set if
1. n is a positive integer or 0
2. n is >= the number of the function's formal arguments
3. n is >= the number of the function's actual arguments

See the attached testcase. Expected output:
1337
1337
1337
1337
1337

Actual output:
undefined
undefined
1337
undefined
1337
(Reporter)

Comment 1

12 years ago
Created attachment 182057 [details]
testcase (shell or browser)

Updated

12 years ago
Keywords: testcase
(Reporter)

Comment 2

12 years ago
This could be related: Given the following script

  function fun (x) {
      x = 4711
      document.writeln( arguments[0] )
  }
  fun(1), fun()

SpiderMonkey and Navigator 3.04 output '4711 4711'. If I understand the last 
point of ECMA262 10.1.8 correctly the right result is '4711 undefined' and that 
is what I get in the other JS engines (IE, Opera, Rhino).
(Assignee)

Comment 3

12 years ago
Old bug.  Makes me regret conceding so much about arguments to MS back in the day.

/be
(Assignee)

Comment 4

12 years ago
*** Bug 299645 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

12 years ago
This is an ECMA conformance issue that we can fix soon.  I have a patch, and
it's safe for 1.8b4.

/be
Assignee: general → brendan
Flags: blocking1.8b4+
Keywords: js1.5
Priority: -- → P3
Target Milestone: --- → mozilla1.8beta4
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

12 years ago
Created attachment 189021 [details] [diff] [review]
fix

ECMA-262 Ed. 3, 10.1.8 is hard to read in terms of SpiderMonkey.  The key is
that only actual the k arguments are reflected into the arguments object as
indexed elements, and then only the first n, where n is the number of formal
parameters, share value storage with the formal parameters.

If k >= n, then it's of course perfectly fine in SpiderMonkey to use
fp->argv[k] for value storage (there's no formal to share with, but there's no
need for a full arguments object).  If k < n, we may need an arguments object
to hold values indexed at i >= k.  These would not be actual argument values (k
is the number of actuals), just values that the callee stores for grins.

/be
Attachment #189021 - Flags: review?(shaver)
Comment on attachment 189021 [details] [diff] [review]
fix

r=shaver
Attachment #189021 - Flags: review?(shaver) → review+
(Assignee)

Comment 8

12 years ago
Comment on attachment 189021 [details] [diff] [review]
fix

Yet another nit-picky ECMA thing to get right with a spot fix.

/be
Attachment #189021 - Flags: approval1.8b4+
(Assignee)

Comment 9

12 years ago
Fixed.

/be
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Flags: testcase?

Comment 10

12 years ago
Checking in regress-292215.js;
/cvsroot/mozilla/js/tests/js1_5/Function/regress-292215.js,v  <--  regress-292215.js
initial revision: 1.1
Flags: testcase? → testcase+

Updated

12 years ago
Keywords: fixed1.8

Comment 11

11 years ago
verified fixed on trunk and 1.8.x branches.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8 → verified1.8
You need to log in before you can comment on or make changes to this bug.