On May 22, 2014, at 4:01 AM, Dmitry Lomov wrote: > > > Wait, am I reading this correctly that after a backing array buffer is > neutered, accesses to typed arrays within [0...original length) should throw > and accesses outside that range should continue to return 'undefined'? This > is definitely not what is shipping in Chrome, and looks like a compat hazard > way bigger than 'subarray'. >
Do you think any non-buggy code actually depends upon being able to index into a neutered typed array? But, yes, that's the implication of the current ES6 spec. language. Essentially, TypedArray objects (or at least the actual indexed property access operations don't know anything about neutered ArrayBuffers so they do their normal bounds checks and and if an index is in bounds the actual access gets delegated to the ArrayBuffer which throws. This can easily be changed (in the spec.) so, that TypedArrays have an explicit "is the buffer neutered" guard prior to bounds checking. The more interesting question is the general concept of TypedArrays returning undefined on out-of-bounds accesses which (particularly after the neutering) seems to be a significant bug farm. Admittedly trying to changing it would be a breaking change, but would it break anything that wasn't already buggy. I've been talking to Luke Wagner about this it at appears that one of the sources of out-of-bound accesses to Typed Arrays are Emscripten compilation bugs that should be fixed. (and this is a good example, of the danger of the current behavior. It's masking bugs that need to be discovered and fixed.). Out-of-bounds access have also been observed in non-Emscripten code, for example [1] [2]. Note that this is another example, of the current behavior masking logic bugs in the application code. It's still early days for production use of TypedArrays and maybe its not too late to evangelize fixing any major apps that depend upon out-of-bounds accesses or accessed to neutered arrays. In TC39 we talk about having a "five fingers" breaking change budget for ES6. If we think a breaking change is important enough (and rare enough) we will try to evangelize away dependency upon it so we can make the change. But, we figure we can probably only get away with around 5 or less of such changes. Perhaps, throwing on out-of-bound typed array access should get allotted to a finger. I'm pretty sure that it would be the right thing to do from a long term perspective and that within a couple years we would have no regrets. I actually think there are two risk levels of breaking changes we should consider (and experiment with) 1) Throw on all indexed accessed to typed arrays with neutered buffers. Note that this will only impact existing code that actually transfers typed arrays/ArrayBuffers and then (clearly for buggy reasons) try to access the transferred array. This actually seem like a pretty low risk change to me. 2) Throw on all out-of-bounds indexed accesses to typed arrays. This will impact existing code that contains out-of-bounds accesses (presumable either array creation size bugs or index computation bugs) including things like buggy Emscripten code. This is a higher risk change, but may be possible with evangelism. It would be possible to do 1) and not do 2). But, both would be best. We should at least consider these alternative rather accept without question another permanent JS WTF behavior. Allen [1]: https://code.google.com/p/octane-benchmark/issues/detail?id=11 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=845873
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
