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.