Properly define possible errno results

[ritave]

Currently, the possible results of sys calls returning errno are an undefined behaviour.

For example, let's get args get. What should be the effect if the pointer is out of bounds, should it trap the execution, or return errno? If it should return errno, which one?
What other errno's can occur resulting from args.get function and when?

[pchickey]

This is a good line of inquiry and we could make some significant improvements to WASI's representation of errors.

WASI interfaces should never trap, except for functions marked noreturn, which should always terminate execution, whether through trapping or some other runtime-provided mechanism. When passed an out-of-bounds pointer, implementations currently use errno.inval to indicate that the argument was invalid.

I don't think WASI's current use of the posix-style all-errors-in-one-enum errno is the design we should stick with forever. Most (maybe all) functions should only ever return a small subset of the variants in errno. One way to start figuring out a better design would be to audit each function and enumerate all the variants it can reasonably return. Once we have that, we can start defining new specialized error enums that work for smaller families of functions, switching the family from errno to the new enum in ephemeral. The wasi-libc implementation would still need to convert these specialized enums back into an errno, but other guest and host-side implementations of the WASI interfaces would benefit.

[bjorn3]

For syscalls like open it would be possible to for example return EHOSTDOWN when the file is stored on a different machine and accessed using some network file system, or just because somebody decided to (ab)use fuse. It could also return any other error code.

[linclark]

Thanks for filing this. As Pat speculated above, we decided against having the "all-errors-in-one-enum errno".

Once WASI modularization is complete, we'll be refactoring the errors so that each module only contains the errors that are relevant to its functions. In the later stages of that process, we will be auditing each function to enumerate all the variants it can reasonably return.

That work is taking place in various proposal repos and being tracked in the project linked above, so I'm going to close this one out.

[codefromthecrypt]

Is it required to delay definition of errors until post modularization? Currently implementations use different codes due to this not being addressed for two years. This means they are not compatible in material ways as well cause implementation delays as people fumble around wondering which codes to use.

[sunfishcode]

It isn't strictly required to wait for modularization, but modularization isn't the only thing happening here, there's also the transition to the new wit-based tooling, along with the new interface-types support.

For random_get specifically, I'm expecting to propose that it never return any errors, so that we don't end up with applications having fallback paths for the case where it fails, which are historically error-prone.

[programmerjake]

For random_get specifically, I'm expecting to propose that it never return any errors, so that we don't end up with applications having fallback paths for the case where it fails, which are historically error-prone.

that is a problem for those who specifically want 100% deterministic execution, part of that is that random_get can't return random results (because those aren't repeatable), so essentially the only reasonable option is to return an error.

[sunfishcode]

Environments which require 100% deterministic execution should ideally not provide the random_get export, so that applications that attempt to import it fail at link time rather than at runtime.

[programmerjake]

Environments which require 100% deterministic execution should ideally not provide the random_get export, so that applications that attempt to import it fail at link time rather than at runtime.

ah, yeah, that likely works better

[codefromthecrypt]

Just to clarify the problem is more general than nuance of random source. For example, a great start would be defining code one should use when pointers for result params are invalid (ex. argc is out of range of the underlying memory). Maybe with that carved out, we can proceed one-by-one with functions?

[sunfishcode]

For the most part, WASI in its current form falls back on POSIX-like conventions. POSIX would likely use EINVAL for a situation where a pointer or length is invalid, so that makes sense for WASI's current argv/argc conventions.

The broader situation with the argv/argc functions is that we haven't put much effort into polishing the details, because we've been preparing to redesign them entirely when we have the new interface types tooling underneath us. If anyone is interested in working on error codes, the filesystem functions might be a good place to start. The spec is here, and already converted to the new wit format, and it's ready to accept PRs.