Skip to content
This repository has been archived by the owner on Apr 21, 2021. It is now read-only.

Latest commit

 

History

History
94 lines (62 loc) · 3.66 KB

README.md

File metadata and controls

94 lines (62 loc) · 3.66 KB

This repo is merged with Freeze ArrayBuffer.

Fixed view of ArrayBuffer

Status

Champion(s): Jack Works

Author(s): CrimsonCodes0, Jack Works

Stage: 0

Related proposal: Freeze ArrayBuffer and Readonly view to ArrayBuffer

Presentations

Motivation

Provide a fixed view to an ArrayBuffer so the third party code won't be able to access the data they're not supposed to access.

This is impossible today because the .buffer property on the TypedArray and DataView can get the original ArrayBuffer.

Use cases

Consider an application using JavaScript and WebAssembly, communicating through the Wasm heap.

If the JS wants to pass around a read-only slice of the Wasm heap (a JS ArrayBuffer object), the JS must either pass around a TypedArray and always make sure to use it's .byteLength and .byteOffset properties to ensure correct usage, or copy the memory in the slice into a new ArrayBuffer.

One wants the slice to be read-only in order to prevent writing to the memory, and one doesn't want to move around the entire ArrayBuffer object, as that would allow reading into the memory at practically arbitrary locations.

Without being able to do both, view a section of an ArrayBuffer, and mark it as read-only, developers will have to find a workaround, which will likely come to creating ad-hoc wrapper classes or copying.

-- By CrimsonCodes0 https://github.com/Jack-Works/proposal-arraybuffer-fixed-view/issues/1

Possible API design

Possible API 1:

Add a new option to the TypedArray API and DataView API.

const x = new Uint8Array(buffer, { byteOffset: 4, length: 12, fixed: true })
x.buffer // undefined

By limiting the .buffer property to get the original buffer, we can prevent the holder of x to construct full access to the underlying ArrayBuffer.

Possible API 2:

Add a new kind of ArrayBuffer. It is a "proxy" to the ArrayBuffer which limits the view window.

// Possible API 1
const slice = new ArrayBufferSlice(buffer, 4, 12)
const x = new Uint8Array(slice)
x.buffer === slice
x.byteOffset === 0
x.byteLength === 12
// Possible API 2
const slice = new ArrayBuffer(buffer, 4, 12)
const x = new Uint8Array(slice)
x.buffer === slice
x.buffer instanceof ArrayBuffer
x.byteOffset === 0
x.byteLength === 12

From the perspective of the holder of x, it looks like they're accessing the full ArrayBuffer thus there is no way to expand the view anymore.