Wasmtime GitHub notifications bot (Nov 17 2025 at 19:49): Wasmtime GitHub notifications bot (Nov 17 2025 at 19:49):cfallin requested rvolosatovs for a review on PR #12037.
Wasmtime GitHub notifications bot (Nov 17 2025 at 19:49):cfallin opened PR #12037 from cfallin:exceptions-fuzzed-and-c-api to bytecodealliance:main:
Noticed while reviewing another docs update: we still state that the exceptions proposal is not fuzzed, and has no C API support. Neither is true anymore, AFAIK:
- We fuzz exceptions via our usual infrastructure and we had a number of fuzzbugs come in when we first merged support.
- We added C API support for enabling exceptions in #11861.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Nov 17 2025 at 19:49):cfallin requested wasmtime-default-reviewers for a review on PR #12037.
Wasmtime GitHub notifications bot (Nov 17 2025 at 19:49):cfallin requested alexcrichton for a review on PR #12037.
Wasmtime GitHub notifications bot (Nov 17 2025 at 19:49):cfallin commented on PR #12037:
(This'll be a merge conflict with #12036, sorry Alex! And if you disagree that we have enough fuzzing to check the box here I'm happy to remove that part; we don't have a specific target of course but we do fuzz it overall)
Wasmtime GitHub notifications bot (Nov 17 2025 at 19:58):alexcrichton commented on PR #12037:
For the C API I believe one missing piece is bindings for
exnrefvalues. I don't think that the type is plumbed in the API yet nor the ability to create/manage the references. I think all the pieces are there, however, and it's mostly just a matter of copying the anyref constructors/inspectors/etc forexnrefas well.For fuzzing I could go sort of either way myself. On one hand the preexisting wasm-smith-based fuzzing is good in that it creates interesting shapes of code. In that sense I feel like it fuzzes the compiler side of exceptions relatively well. On the other hand though, like with most other wasm-smith-based-fuzzing, I feel like it's probably leaving quite a lot on the table in terms of runtime-handling fuzzing. For example I suspect everything either immediately throws-and-doesn't-catch or never throws because intersting payloads are never on the stack (or something like that). In that sense I do think there's very real space for a more interesting fuzzer exceptions-wise, primarily focused on the runtime behavior of exceptions as opposed to the compile-time-behavior. I don't have a concrete idea though what such a fuzzer would precisely be fuzzing, and whether we block on that for enabling exceptions, I'm not sure. Perhaps a good meeting topic as well?
At the very least though adding a :construction: symbol plus a footnote explaining the current situation is definitely ok though.
Wasmtime GitHub notifications bot (Nov 17 2025 at 21:29):cfallin updated PR #12037.
Wasmtime GitHub notifications bot (Nov 17 2025 at 21:29):cfallin commented on PR #12037:
Good points! I had completely forgotten about the host-API-creates-exnrefs side of the C API -- indeed we'll want that. Updated both host API and fuzzing to :work_in_progress: and we can talk about fuzzing more in the next meeting.
Wasmtime GitHub notifications bot (Nov 17 2025 at 21:30):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Nov 17 2025 at 21:32):cfallin has enabled auto merge for PR #12037.
Wasmtime GitHub notifications bot (Nov 17 2025 at 22:05):cfallin merged PR #12037.
Last updated: Dec 06 2025 at 06:05 UTC