-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ArrayBuffer ranged views #11
Comments
The "read-only view" in this proposal includes both TypedArray family and DataView. Can a read-only DataView satisfy your needs? |
@Jack-Works I'm not sure if we're on the same page with the problem. Consider this example: const over_allocated_buffer = Uint8Array.of(0, 1, 2, 3, 4, 5);
function get_pair() {
const ro_data_view = new DataView(over_allocated_buffer, 0, 2, { readonly: true });
return ro_data_view;
} The function assert(get_pair().byteLength === 2); But, we can easily access the DataView#buffer property... // Accessing implementation detail
const { buffer } = get_pair();
const view = new Uint8Array(buffer):
// reads past 2 bytes
console.log(view); ... leading us back around to the problem with using a TypedArray. |
Ok, I understand your question, the point here is not read-only or not. A possible solution is like this: const slice = new DataView(over_allocated_buffer, 0, 2, { slice: true });
slice.buffer // undefined, therefore no way to escape Then you can read/write on the slice of the buffer but no way to escape. |
A new proposal 🎉 |
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.
Could sliced views be introduced into the proposal alongside read-only views?
The only two questions that I would have regarding an introduction of the idea would be the following:
The text was updated successfully, but these errors were encountered: