Does it make sense to support WASM?

[shepmaster]

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?

[alexcrichton]

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]

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]

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]

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]

There is a C compiler that can intermix with Rust on wasm today. And it seems like for at least int, short, and char, (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]

@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 long and 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]

For an abundance of caution, long and long long have 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, and int on wasm32 are very safe at 8-bit, 16-bit, and 32-bit.

[aochagavia]

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 on libc.

EDIT: nvm, it seems that this has already been addressed by #861

[stoically]

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]

By definition, wasm32-unknown-unknown has no libc. If you want to use emscripten or wasi you can use wasm32-unknown-emscripten or wasm32-wasi, both of which are already supported in the libc crate.

[RReverser]

By definition, wasm32-unknown-unknown has no libc. If you want to use emscripten or wasi you can use wasm32-unknown-emscripten or wasm32-wasi, both of which are already supported in the libc crate.

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]

By definition, wasm32-unknown-unknown has no libc. If you want to use emscripten or wasi you can use wasm32-unknown-emscripten or wasm32-wasi, both of which are already supported in the libc crate.

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.

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]

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-unknown for 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.