✔ wasi-libc: Why are the public constants different to musl? · wasm

Stream: wasm

Topic: ✔ wasi-libc: Why are the public constants different to musl?

Scott Waye (Mar 08 2022 at 21:51):

For example https://github.com/WebAssembly/wasi-libc/blob/ad5133410f66b93a2381db5b542aad5e0964db96/libc-bottom-half/headers/public/__header_fcntl.h#L20 compared to musl libc it is #define O_RDONLY 00 Seems like wasm-libc has always been like this, but it would be better if it used the same constants as wasm built with musl libc (e.g. emscripten), cannot be run with wasmtime.

wasi-libc/__header_fcntl.h at ad5133410f66b93a2381db5b542aad5e0964db96 · WebAssembly/wasi-libc

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

Scott Waye (Mar 08 2022 at 21:52):

This therefore means that runtimes, like dotnet, need 2 different runtimes depending on what the host is which is not great.

Dan Gohman (Mar 08 2022 at 21:54):

The original reason is that cloudlibc did it that way, and the code comes from there.

Dan Gohman (Mar 08 2022 at 21:56):

From a libc maintainer perspective, these values are implementation details. musl only has a single value because musl only supports Linux, where O_RDONLY always has the same value. But across other platforms, it can have different values.

Dan Gohman (Mar 08 2022 at 21:57):

wasi-libc is not ABI-compatible with Emscripten in numerous ways, and no one has ever volunteered to do the work to make it be so.

Dan Gohman (Mar 08 2022 at 22:01):

That said, from a practical perspective, some C / POSIX constants are sufficiently "well known" that we do make efforts to align their values with the well-known values. This is somewhat subjective, so whether O_RDONLY should qualify as having a well-known value would come down to how it's used in practice, how you're using it.

Scott Waye (Mar 08 2022 at 22:06):

Thanks. Trying to use open from the dotnet runtime to make the wasm runtime similar to the Unix runtime, reducing developer cost. I suppose the argument is that dotnet should not do that, but go straight to the wasi syscalls where the flags are well defined.

Scott Waye (Mar 08 2022 at 22:08):

Which would be ok in the long run, but emscripten's wasi support is a WIP, whereas it's libc support is good.

Scott Waye (Mar 08 2022 at 22:10):

Not that that helps much. The only system that is at fault here is the dotnet runtime, I just tried to take the libc route (emscripten and wasi-libc) and came unstuck.

Notification Bot (Mar 10 2022 at 12:14):

Scott Waye has marked this topic as resolved.

Last updated: Dec 23 2024 at 13:07 UTC