ArrayBuffer neutering

Dmitry Lomov dslomov at
Thu May 22 04:01:25 PDT 2014

On Wed, May 21, 2014 at 9:04 PM, Allen Wirfs-Brock <allen at>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
>  and
> (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 (
>  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'.


Google Germany GmbH
*Dienerstr. 12, 80331 München., DE *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list