search

WebAssembly / WASI

WebAssembly System Interface
Other
4.84k stars 251 forks source link

Error codes from filesystem functions #555

Open zoraaver opened 1 year ago

zoraaver commented 1 year ago

While attempting to fix the rust WASI tests on WAMR, I ran into various discrepancies between the expected error codes for various filesystem operations and the expected error codes (presumably suited for wasmtime).

Since we don't seem to document the returned error codes for the filesystem functions, I was wondering whether we should? If we don't want to explicitly document every error code for each condition, defaulting to POSIX might be another option. But I'm not sure if this is a) useful b) overly restrictive

Any thoughts or suggestions would be appreciated, thanks!

loganek commented 1 year ago

I personally like the idea of having an error code consistency across runtimes/platforms, as that truly enables us to "write once, run everywhere" in the WASI world. Whereas there are cases where error codes are just for logging / debugging purpose, there are cases where they are actionable and code can rely on them.

Having said that, I do agree they introduce quite a bit of overhead in terms of documentation, so we'd need to do some incremental work to update all of that. I'm curious what approach is planned for preview2 interfaces - is there going to be a list of error codes for each function (e.g. filesystem, cc: @sunfishcode )?

abrown commented 1 year ago

I agree with the idea of being consistent, but I wonder if this error code problem goes away due to using WIT to define preview2. Previously we had to share an error code space among many functions; now each function can return its own error enum that only contains the applicable error cases.

sunfishcode commented 1 year ago

I also agree this would be nice to do. If anyone is interested, I guess the first step is to start making lists of errors for each function.

yamt commented 1 year ago

I agree with the idea of being consistent, but I wonder if this error code problem goes away due to using WIT to define preview2. Previously we had to share an error code space among many functions; now each function can return its own error enum that only contains the applicable error cases.

i guess it won't go away as far as we will support some mappings to posix api.