Skip to content
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

Make wasm_global_set a safe API. #133

Closed

Conversation

sunfishcode
Copy link
Member

Make wasm_global_set a safe API by allowing it to return a trap
in error cases.

Traps in the wasm spec are used to report runtime errors, and the
errors wasm_global_set reports are things that wasm would catch
at validation time.

Nevertheless, using a trap here is consistent with the official
JS API raising exceptions on the same conditions. And, it provides
a message explaining the reason for the error.

To support users for whom mutablility and type checks are believed
to be unacceptable overhead, add a wasm_global_set_unsafe function
which skips those checks, at the penalty of undefined behavior.

Make `wasm_global_set` a safe API by allowing it to return a trap
in error cases.

Traps in the wasm spec are used to report runtime errors, and the
errors `wasm_global_set` reports are things that wasm would catch
at validation time.

Nevertheless, using a trap here is consistent with the official
JS API raising exceptions on the same conditions. And, it provides
a message explaining the reason for the error.

To support users for whom mutablility and type checks are believed
to be unacceptable overhead, add a `wasm_global_set_unsafe` function
which skips those checks, at the penalty of undefined behavior.
@sunfishcode
Copy link
Member Author

Note that this PR does not yet update the wasm-c.cc implementation or the C++ API, so it's not ready to be merged as-is. This just illustrates a change to the C API so that we can discuss it in detail.

@rossberg
Copy link
Member

Let's perhaps reach a conclusion on issue #132 first? Personally, I still think this is not a natural or principled way to go about incorrect API usage in a language like C. Adding arbitrary one-off "unsafe" functions -- when everything is unsafe anyway -- kind of reenforces that point.

I don't think comparison to the JS API is particularly helpful, since that is (1) for a safe language and (2) not designed for efficiently building safer, more high-level API abstractions on top.

@sunfishcode
Copy link
Member Author

Superseded by #134.

@sunfishcode sunfishcode closed this Apr 6, 2020
@sunfishcode sunfishcode deleted the wasm-set-global-safety branch April 6, 2020 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants