If a JSLI is called to a value in the global scope that is null this would crash the Vireo runtime. A case was added to handle null values for properties on the global object (where undefined was already handled).
If a user configures the JavaScriptInvoke for a TypedArray buffer as a parameter, the buffer is tied directly to Vireo's underlying wasm memory. If they write to the buffer, pass the buffer to an unexpecting api (ex: https://github.com/daphtdazz/WebBLE/issues/28), or transfer the buffer to another worker this will corrupt vireo's memory / crash the runtime.
Now instead we create a copy of the buffer to return to the user. This is a performance hit but is a safer default configuration. This is inline with the idea that JavaScriptInvoke calls should be safe by default and optimizations can be added in the future when exposed clearly (ie direct memory access / reduced error handling, direct vireo api access, etc).
This PR addresses two behaviors:
If a JSLI is called to a value in the global scope that is null this would crash the Vireo runtime. A case was added to handle null values for properties on the global object (where
undefinedwas already handled).If a user configures the JavaScriptInvoke for a TypedArray buffer as a parameter, the buffer is tied directly to Vireo's underlying wasm memory. If they write to the buffer, pass the buffer to an unexpecting api (ex: https://github.com/daphtdazz/WebBLE/issues/28), or transfer the buffer to another worker this will corrupt vireo's memory / crash the runtime.
Now instead we create a copy of the buffer to return to the user. This is a performance hit but is a safer default configuration. This is inline with the idea that JavaScriptInvoke calls should be safe by default and optimizations can be added in the future when exposed clearly (ie direct memory access / reduced error handling, direct vireo api access, etc).