Cannot modify length property of TypedArray

[andreabergia]

This is not allowed by rhino:

var a = new Int8Array([1,2,3]);
Object.defineProperty(a, 'length', {configurable: true, value: 42});

[p-bakker]

Do you know if this is just a misconfigured propertyDescriptor, or is there more to it?

[p-bakker]

I'm not sure I get what this case is about. Unless I'm reading things wrong, the length property of a TypedArray is to be an accessor property without a set, see https://tc39.es/ecma262/multipage/indexed-collections.html#sec-get-%typedarray%.prototype.length

The above referenced spec doesn't say anything more about the setup of the property, meaning https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-property-attributes kicks in, which says that unless specified the defaults kick in and configurable is false by default

So that leads me to conclude that it shouldn't be possible to redefine the length property

Or am I missing something?

[andreabergia]

I haven't checked the spec, but there's a lot of test262 cases that fail because of this issue. They are those named get-length-uses-internal-arraylength.js, where they do something like this:

Object.defineProperty(TypedArray.prototype, "length", {value: 0});

or

Object.defineProperty(TypedArray.prototype, "length", desc);

[p-bakker]

Had a look at /test262/test/built-ins/TypedArray/prototype/every/get-length-uses-internal-arraylength.js: the test likely already bombs out because it does Object.defineProperty(TypedArray.prototype, "length", desc);, while TypedArray(.prototype)is undefined, resulting in a TypeError.

Once the test would be able to get passed that hurdle, I'm not sure what would happen: the test tries to reconfigure the length property to see whether the internal code never looks at the length property(as per the spec it should look at the [ArrayLength] internal slot).

While I think our impl. does that, the test may or may not bomb out because Rhino seems to have some flaws in redefining properties.

Long story short I don't think we need this case:

• we already have a case for the missing TypedArray prototype
• we already have several cases related to issues redefining PropertyDescriptors

Agree?