Phabricator will be unavailable due to database maintenance from 14:00 UTC until 18:00 UTC on Saturday, October 13, 2018.
Bugzilla will remain up during this time. All users have been logged out of Bugzilla
Bugzilla will remain up during this time. All users have been logged out of Bugzilla
Throw on indexing into detached ArrayBuffers instead of returning `undefined`
NEW
Assigned to
Status
()
People
(Reporter: till, Assigned: evilpie)
Tracking
(Blocks: 2 bugs)
Firefox Tracking Flags
(Not tracked)
Details
(URL)
Attachments
(2 attachments)
|
1.22 KB,
patch
|
Details | Diff | Splinter Review | |
|
11.69 KB,
patch
|
Details | Diff | Splinter Review |
Section 9.4.5.8, step 5 now specifies that indexing should throw instead of failing silently on detached buffers. I have my doubts regarding the web compatibility of this change. Ideally we should get telemetry data on this first.
Updated•2 years ago
|
||
Assignee: nobody → winter2718
| (Assignee) | ||
Comment 1•4 months ago
|
||
Edge actually throws for at least [[Get]], [[Set]] and [[DefineProperty] on detached arrays. So it seems like this is something we could actually implement.
| (Assignee) | ||
Updated•4 months ago
|
||
Assignee: nobody → evilpies
| (Assignee) | ||
Updated•4 months ago
|
||
| (Assignee) | ||
Updated•4 months ago
|
||
See Also: → https://github.com/tc39/ecma262/issues/678
| (Assignee) | ||
Comment 2•3 months ago
|
||
Created attachment 8989041 [details] [diff] [review] patch So, this was basically my first idea, throwing for typed arrays lookups in LookupOwnPropertyInline. I think this would basically work, but is so far from how the spec works, so I am not sure if this will always be correct. I feel like it would be better to do this more explicitly. André what do you think? In IonMonkey LoadTypedArrayElementHole and StoreTypedArrayElementHole need code on the OOB to fail when the array is detached. In CacheIR at least StoreTypedElement, LoadTypedElementExistsResult.
Attachment #8989041 -
Flags: feedback?(andrebargull)
| (Assignee) | ||
Updated•3 months ago
|
||
Attachment #8989041 -
Attachment is patch: true
| (Assignee) | ||
Comment 3•3 months ago
|
||
This patch would violate the execution order defined in the spec, so we need to instead manually patch all the different operations.
| (Assignee) | ||
Updated•3 months ago
|
||
Attachment #8989041 -
Flags: feedback?(andrebargull)
| (Assignee) | ||
Comment 4•2 months ago
|
||
Created attachment 8997606 [details] [diff] [review] Patch v2 This is a new approach. I added special handling for typed arrays to Get, Set, Has, GetOwnPropertyDescriptor and disallowed typed array indexes in LookupOwnPropertyInline. While this handles probably handles like 90% of the code, there is _a lot_ of code that ends up calling LookupOwnPropertyInline. For example direct callers of NativeLookupOwnProperty, like HasOwnProperty. I am really not sure what the best way forward is here.
| (Assignee) | ||
Updated•2 months ago
|
||
Attachment #8997606 -
Flags: feedback?(jorendorff)
Attachment #8997606 -
Flags: feedback?(andrebargull)
| (Assignee) | ||
Comment 5•2 months ago
|
||
Comment on attachment 8997606 [details] [diff] [review] Patch v2 Afte
Attachment #8997606 -
Flags: feedback?(jorendorff)
Attachment #8997606 -
Flags: feedback?(andrebargull)
| (Assignee) | ||
Comment 6•2 months ago
|
||
After sleeping on this for a bit I realized we should actually be okay with throwing for detached buffers in LookupOwnProperty descriptor! Only [[Set]] and [[DefineOwnProperty]] don't check for IsDetachedBuffer in their first observable step. So in theory it should be ok to keep the custom implementation for those two and remove all the other ones and just start throwing.
| (Assignee) | ||
Comment 7•2 months ago
|
||
I think I found another interesting difference between our implementation and the spec: Because we set [[ArrayLength]] to zero, stuff like Reflect.ownKeys() will return an empty array, but from my understanding the Spec wants those to still be returned.
Comment 8•2 months ago
|
||
Correct. There are actually bad people who know and abuse this difference (bug 1381474, bug 1381469). :-) *goes away whistling*
You need to log in
before you can comment on or make changes to this bug.
Description
•