Repository navigation
Does it make sense to support WASM? #858
Description
In the Omnibus, I recommend using libc to provide the basic types when doing FFI. Trying to do so with the newly-landed WASM support yields 70+ errors.
Should libc have the basic types defined for WASM but basically no functions?
Reacted by Steve Klabnik, remexre, Yuji Sugiura, stoically, Felipe S. S. Schneider, Guilherme Werner, Kelvin Steiner and Ziyak Jehangir
Activity
[-]Does it make sense to support wasm?[/-][+]Does it make sense to support WASM?[/+]alexcrichton commentedon Nov 26, 2017
I'd personally say "no" in the sense that wasm has no libc, and hence talking about a "c_int" doesn't even really have an answer. The only FFI types in wasm right now are i32/i64/f32/f64/u32/u64 (afaik), so at least for wasm I think those are the types you'd want to use.
When there's perhaps a prevelant C compiler that can intermix with Rust code we could arbitrarily decide "that's the C ABI" and then just match that, but such a C compiler would likely want to be relatively standard...
shepmaster commentedon Nov 26, 2017
I understand your reasoning, but I also think this will make it really annoying for widely-applicable crates to be used in e.g. FFI, no-std, embedded, and wasm contexts. Is there a better solution for such types of crates?
alexcrichton commentedon Nov 27, 2017
I agree yeah that we don't want things to be super painful, but I guess at this point I feel like it's too early to make decisions about wasm and libc. I'd sort of like to gather more data on this topic before adding something to this crate where it's insta-stable and we can basically never change it.
shepmaster commentedon Nov 27, 2017
Ok. I'll go ahead and close this; hopefully if anyone can provide that "more data" in whatever form, they can add it here!
sunfishcode commentedon Nov 29, 2017
There is a C compiler that can intermix with Rust on wasm today. And it seems like for at least
int,short, andchar, (and their unsigned counterparts) there are obvious sizes which are unlikely to ever differ. Could you clarify what additional data you're looking for here?alexcrichton commentedon Nov 30, 2017
@sunfishcode oh sure yeah I think in theory it could work but for now w/ our bundling of the linker it may not work in practice...
Also are we sure to have definitions for types like
longand such? It's true though that if there are "obvious and unchanging" definitions for types like you mentioned then it seems fine to me to add those!sunfishcode commentedon Nov 30, 2017
For an abundance of caution,
longandlong longhave a slight risk. In Emscripten and plain clang on wasm32 they're 32-bit and 64-bit, respectively, and are unlikely to ever change, but it's conceivable that someone creating a new C compiler could want them to be 64-bit and 128-bit, for example.char,short, andinton wasm32 are very safe at 8-bit, 16-bit, and 32-bit.aochagavia commentedon Nov 30, 2017
Today I ran into this issue. I tried to compile a program to wasm, but it was impossible because I am using
rand, which in turn depends onlibc.EDIT: nvm, it seems that this has already been addressed by #861
stoically commentedon Jan 10, 2020
Sorry for jumping into this old thread. The wasm32 support in llvm/clang is stable since version 8 (~1 year) - could this maybe help with adopting wasm32-unknown-unknown support in libc? I'd be interested to contribute if it's a possible way forward.
gnzlbg commentedon Jan 11, 2020
By definition,
wasm32-unknown-unknownhas no libc. If you want to use emscripten or wasi you can usewasm32-unknown-emscriptenorwasm32-wasi, both of which are already supported in the libc crate.RReverser commentedon Mar 4, 2020
It still has types though, and in many (most?) cases that's all you want - being able to define FFI for C functions to be able to use them from Rust in the same Wasm module.
kylebarron commentedon Mar 23, 2022
Is there any interest in revisiting this for types only for
wasm32-unknown-unknown? Having just the libc types would at least permit downstream libraries to not need to polyfill types manually.FreddyFunk commentedon Aug 21, 2024
I would love if you could revisit this, since for a lot of use cases, this is the final missing link on providing great Rust apps with C dependencies to the web. Most of Rust echosystem for GUIs like egui and graphics libraries like wgpu target only
wasm32-unknown-unknownfor WebAssembly.In my use case for example, I am trying to build a FOSS USB peripherals device manager using Rust that can run "everywhere", including Linux on various CPU architectures and the web utilizing WebUSB. libusb supports as WebAssembly + WebUSB backend for some time now. It seems like the only remaining blocker is libc, which is used in rusb, a safe Rust wrapper for libusb.
Also, this merged PR to Rust might be helpful, as described in this StackOverflow discussion.
polarathene commentedon Jul 11, 2026
Just a small update to that reference. Since Rust 1.89 (Aug 2025), the WASM C ABI has switched from
legacytospec, thus now has a standards compliant C ABI. That flag (-Z wasm-c-abi=spec) introduced in the PR (available since Rust 1.79 in June 2024), is no longer necessary 👍