ArrayBuffer neutering

Allen Wirfs-Brock allen at
Tue May 20 08:25:12 PDT 2014

On May 20, 2014, at 7:37 AM, Anne van Kesteren wrote:

> "ArrayBuffer instances whose [[ArrayBufferData]] is null are
> considered to be neutered" However, most algorithms only check for it
> being undefined (and sometimes missing).

The operations on ArrayBuffers all have lines that are the equivalent of:

1 Let block be arrayBuffer’s [[ArrayBufferData]] internal slot.
2 If block is undefined or null, then throw a TypeError exception.

undefined is used as an indication that the ArrayBuffer has not yet been initialized.  null is an indication that it has been neutered.


Anything that access the actual data of an ArrayBuffer ultimately goes through one of the above operations or methods.

Let me know if you see any path in the spec. that doesn't.

> In addition, the behavior defined seems incompatible with what is in browsers:

The ES6 TypedArray/ArrayBuffer spec. was written closely following the Khronos spec. which is pretty vague about what happens when an ArrayBuffer is neutered.
> <script>
> var a = new ArrayBuffer(12)
> onmessage = function(e) { w(; w(; w(a);
> w(a.byteLength) }
> postMessage(a, "", [a])
> </script>
> The above will log:
> object "[object ArrayBuffer]" (0 props)
> 12
> object "[object ArrayBuffer]" (0 props)
> 0
> And not throw a TypeError as suggested.

Is this behavior actually specified anywhere.  If not, do all significant browsers implemented this behavior.  Does web content depend upon it.  (What use could be made of knowing the (former) length of a neutered ArrayBuffer.

It's a trivial change to make to the ES spec. if it's needed.  Mostly I'm trying to understand the requirements that would motivate the change.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list