Bug 163417 – Array methods are incorrect with objects whose "length" exceeds 2 ** 32 - 1

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Mark Lam]

Step 8 of the Array.prototype.splice spec (https://tc39.github.io/ecma262/#sec-array.prototype.splice) states that we should throw a TypeError if the spliced array's length will exceed 2^53-1.  This is gated on the JSArray getLength() convenience function being updated to return a length value that is greater than 32-bits.  This issue is only a compliance issue in a contrived example, e.g.

    var maxLength = (2 ** 53) - 1;
    Array.prototype.splice.call({ length: maxLength }, maxLength, 0, 1, 2, 3);

In real world code, the JSC runtime prevents us from creating arrays with a length that exceeds UINT_MAX.  We're also bounded on the number of args that we pass to Array.prototype.splice.  As a result, we can never splice together an array that gets anywhere near 2^53-1.  We'll get an OutOfMemoryError long before then.

[Mark Lam]

Created attachment 291531 [details]
archiving test case for step 8 of the spec.

[Alexey Shvayka]

Apart from Array.prototype.splice, other Array methods (mostly ones that are implemented in C++) are affected.
https://github.com/tc39/test262/pull/2509 completes test coverage for those, allowing them to be fixed with a single patch.

[Alexey Shvayka]

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

[Alexey Shvayka]

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

[Alexey Shvayka]

Created attachment 395381 [details]
WIP Patch

WIP

[Alexey Shvayka]

The following Array.prototype.* methods are affected:
  indexOf (slow path)
  lastIndexOf (slow path)
  pop (slow path)
  push
  reverse (slow path)
  slice (slow path)
  splice
  unshift

Given that fast paths are affected, we can't just wrap indices in Identifier::from().
Instead, we need to add support for indices > MAX_ARRAY_INDEX in:
  get
  hasProperty
  putDirectIndex
  deletePropertyByIndex
(apart from few ArrayPrototype.cpp helpers)

1. Should we create new overloads like we already have for get():
  ALWAYS_INLINE JSValue JSValue::get(JSGlobalObject* globalObject, uint64_t propertyName) const
or promote `unsigned` parameter types of existing declarations?

2. Should we use `double` (toLength() return value, Identifier::from() argument type) or `uint64_t`
(argument type of speciesConstructArray() and slowJoin())?

[Alexey Shvayka]

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

[Alexey Shvayka]

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

[Alexey Shvayka]

*** This bug has been marked as a duplicate of bug 211205 ***