On Wed, May 21, 2014 at 9:04 PM, Allen Wirfs-Brock <[email protected]>wrote: > > Yes, as currently spec'ed [[Get]] and [[Set]] operations upon TypedArray > instances throw if the backing ArrayBuffer has been neutered. But the > reason is in > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-integerindexedelementget > and > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-integerindexedelementset > > > (IntegerIndexed exotic objects are the ES underlying specification type > that is used for all Typed Array instances). > > Integer indexed property access (eg, ta[5] ) return undefined (on > [[Get]]'s) that are outside of the 0..originalLength-1 range of the array. > This test is specified in terms of an internal [[ArrayLength]] property > that is immutably set to the original defined size of the array. So the > spec. currently say an "in original array range" access on a TypedArray > with a neutered ArrayBuffer will be "in range" but the call to > GetValueFromBuffer will throw because the ArrayBuffer has been neutered. > > What happens to the length of a neutered typed array > view in the ES6 spec? Does it become 0 as in the Khronos typed array > spec? > > > The length property of an Typed Array is an accessor property. I just > updated my working draft of the specification of that accessor ( > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-%typedarray%.prototype.length > not > yet updated) and also the accessors for byteLength and byteOffset so they > return 0 when the backing ArrayBuffer is observed to be neutered. > > However, that doesn't directly address the indexed access issues. > Implementations presumably want indexed access to typed arrays to be has > fast as possible, so they are unlikely to want to make a call to a 'length' > accessor property on every indexed access. That's why we specify the > [[ArrayLength]] as private state of the the typed array instance. > > Instead I can either place a IsNeutered guard on the calls to > GetValueInBuffer/SetValueInBuffer from the indexed accessors > or change GetValueInBuffer/SetValueInBuffer to not throw on neutered > buffered accesses. However, this also requires some care to make sure that > DataView accesses continue to throw. > > The bottom line of all of this is we want the fast path for a non-netured > typed array access to be as fast as possible while still behaving safely > (if not reasonably) in the presence of neuterable ArrayBuffers. > > What happens if an index which would have been out of range > before the object was neutered is passed to the indexed getter or > setter? > > Currently, in the ES spec. it is range checked against the original array > length. All out of range accesses return undefined. > > > What happens if the [] operator is used to get or set some > random named property against a neutered typed array view? > > > They just work (assuming that the property isn't an integer index). > Neutering the backing ArrayBuffer doesn't do anything to the ordinary > properties of a typed array instance. >
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'. Dmitry -- Google Germany GmbH *Dienerstr. 12, 80331 München., DE *
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
