292215 - Cannot set arguments[n] under certain circumstances

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Erik Fabert]

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

Comment 1

[Erik Fabert]

Attachment: testcase (shell or browser)

Comment 2

[Erik Fabert]

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).

Comment 3

[Brendan Eich [:brendan]]

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

/be

Comment 4

[Brendan Eich [:brendan]]

*** Bug 299645 has been marked as a duplicate of this bug. ***

Comment 5

[Brendan Eich [:brendan]]

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

/be

Comment 6

[Brendan Eich [:brendan]]

Attachment: 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

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 189021 [details] [diff] [review]
fix

r=shaver

Comment 8

[Brendan Eich [:brendan]]

Comment on attachment 189021 [details] [diff] [review]
fix

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

/be

Comment 9

[Brendan Eich [:brendan]]

Fixed.

/be

Comment 10

[Bob Clary [:bc] (inactive)]

Checking in regress-292215.js;
/cvsroot/mozilla/js/tests/js1_5/Function/regress-292215.js,v  <--  regress-292215.js
initial revision: 1.1

Comment 11

[Bob Clary [:bc] (inactive)]

verified fixed on trunk and 1.8.x branches.