

Github GitHub - Jack-Works/proposal-arraybuffer-fixed-view: A proposal that allo...
source link: https://github.com/Jack-Works/proposal-arraybuffer-fixed-view
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK