Stream: git-wasmtime

Topic: wasmtime / issue #11940 c-api: Dealing with lists is inco...

Wasmtime GitHub notifications bot (Oct 24 2025 at 23:00):

alexcrichton opened issue #11940:

I wanted to write down something that irks me when working with Wasmtime's C/C++ API that I've noticed recently. It boils down to basically the handling of lists throughout the API is pretty inconsistent and varies place-to-place in terms of ownership, semantics, representation, and performance. For example:

• wasm_module_imports fills out wasm_importtype_vec_t* which the caller needs to deallocate.
• wasm_functype_params returns const wasm_valtype_vec_t* owned by the callee.
• wasmtime_instance_export_nth is an iterator-style API of walking over a list (as opposed to returning a list)
• wasm_module_new takes a byte list parameter as const wasm_byte_vec_t*
• wasmtime_module_new takes a byte list parameter as a ptr/len combo
• wasm_func_callback_t takes arguments as const wasm_val_vec_t* and fills out wasm_val_vec_t* as a return
• wasmtime_func_callback_t takes arguments/results as ptr/len combos

Much, if not most, of this is wasm.h idioms clashing with what's natural to implement in Wasmtime. Wasmtime internally has some inconsistencies too, however -- in https://github.com/bytecodealliance/wasmtime/pull/11937 the wasmtime Rust API for getting the types of a function's parameters means that the result looks quite different than other C APIs.

On one hand this is wasm.h-vs-not, but the way we've designed the C API right now is that it's not possible to avoid using wasm.h so users are forced to deal with this no matter what. That's not great, in my opinion, so I wanted to file this issue.

Wasmtime GitHub notifications bot (Oct 24 2025 at 23:00):

alexcrichton added the wasmtime:c-api label to Issue #11940.

Last updated: Jan 10 2026 at 20:04 UTC