Improving the utility of stable memory

Regarding SQLite, I tried to get that going a while ago here:

Progress stalled when I couldn’t get it to build using Nix.

More recently, @FroghubMan got something working here:

It’s a very similar approach to the one I took with a more complete example.

However, I just learned from the following issues (and other sources) that linking C code and targeting wasm32-unknown-unknown might appear to work but can’t really be relied upon.

Currently the wasm32-unknown-emscripten and asmjs-unknown-emscripten targets are the only targets that can be linked with C code because all the other wasm targets use a different ABI

only the wasm32-unknown-emscripten target uses the real C ABI for FFI. All the other targets, including WASI, use the different wasm32_bindgen_compat ABI. You’ve been lucky that your C interop has happened to work, but in general this will not be the case.


Another nice effect of stabilizing this ABI is that the wasm32-unknown-unknown target’s default C ABI can be switched back to matching clang. This longstanding mismatch is due to my own personal mistake with the original definition and the reliance on the mistake in wasm-bindgen . Once the “wasm” ABI is stable, however, I can switch wasm-bindgen to using the “wasm” ABI everywhere and then the compiler can switch the default ABI of the wasm32-unknown-unknown target to match the C ABI of clang.

2 Likes