Open andreabergia opened 3 weeks ago
Do you know if this is just a misconfigured propertyDescriptor, or is there more to it?
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?
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);
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:
Agree?
This is not allowed by rhino: