breaking: use negative version of (-) syscall Errno to replace customized errcodes

[gaukas]

We want to introduce a breaking change before hitting stable (v1) to use the negative version of syscall Errno to replace the custom errcode defined below:

https://github.com/gaukas/water/blob/d382a44fed241087a6a3f8d4e87dc89d5bcf8443/internal/wasm/errors.go#L9-L20

Using the negative Errno saves potentially non-trivial translation between syscall and API, and is more intuitive to those who have background in dealing with syscall.

[gaukas]

@erikziyunchi, @jmwample any thoughts on this? Basically, we will build a translation system to flip the sign of an errno returned by WATER API (imported function) and map it to a syscall.Errno, or revert this process when WATM/host gets an error that needs to be passed to the other. This should go into an internal package of wasip1, and I suppose on water-rs we can easily achieve something similar.

The change need not to be very wide given we did not build too many WATMs in v0 under the influence of the old error code system.

[jmwample]

I guess I am not sure I understand why it is necessary to use the negative values. Is the problem that we have unique error codes that we do not want to collide with regular Errno vaules or that we need to do some custom translation of error codes or something else? Handling the negatation seems trivial, and at the end of the day I expect this will be an internal value anyways (i.e. the value is sent from the water host lib to the water watm lib or vice-versa), but is it necessary?

I guess a second relevant question is how is this presented when given back through the public API as an error? i.e if a func returns a WASMError that would provide an Errno error code do we need extra methods that support the value (like sycall Errno type) or are we wrapping the syscall Errno type in some way?

[gaukas]

why it is necessary to use the negative values

Because we are bound to return 1 value not multiple (we are not enabling experimental multivalue proposal). Currently some API functions return a fd (positive) or an error (negative).

EDIT: Theoretically, multivalue proposal is quite ready and supported by both WASM/WASI runtime we are currently using (wasmtime and wazero) if we configure properly. But since it is still a proposal and not a part of wasip1, I am reluctant to use it considering Go (golang/go) may fail to support it even after they properly implement //go:wasmexport tag.

[gaukas]

how is this presented when given back through the public API as an error

If you meant WATER Runtime Library API by public API, while it is not necessarily relevant to this issue, but the most convenient way is to just return the corresonding syscall.Errno (implementing Error interface) on the host. All available syscall.Errno on wasip1 lives on all other major platforms (unix, windows, etc).

[gaukas]

we have unique error codes that we do not want to collide with regular Errno vaules or that we need to do some custom translation of error codes or something else

Instead, we want to eliminate the uniqueness of error codes we are using between WATMs and Host, so the error handling could be more intuitive.

[gaukas]

As an example here:

https://github.com/gaukas/watm/blob/gaukas/syscall-errno/wasip1/errno.go (private repo as of 01/14/2024)

[gaukas]

Something like this: https://github.com/gaukas/water/commit/2a20d21ada607994e45738f7fcc4a5d1009f232e