Error code for file offsets outside the range of s64

[sunfishcode]

The filesize type is defined as unsigned u64. In POSIX, off_t is a signed type.

Most practical implementations won't support file sizes >= 2⁶³, so: what error code should implementations return if users attempt to create files that large? The natural behavior for POSIX-based implementations is EINVAL, corresponding to inval in wasi-filesystem. That makes sense in POSIX because it corresponds to a request to create a "negative" file size, which is not valid to request. However, size WASI has an unsigned type, perhaps it would be more natural to use insufficient-space?

[sunfishcode]

Most implementations today appear to use inval.

[yagehu]

Just want to add some data points here since I've been doing some fuzzing.

On a 64-bit Linux host with ext4, the maximum offset for which lseek returns OK is 17592186040320, just one block short of 16 TiB.

On Wasmtime, fd_seek with max i64 succeeds. I'm guessing because of the filesystem emulation that happens, no actual seek is performed. Attempting to fd_read after this seek in Wasmtime returns ebadf (8).

On all other Wasm runtimes that I've tested (Wasmer, WAMR, WasmEdge, Node via uvwasi), the native behavior (einval) is passed through.

The 16 TiB limit behavior is almost certainly platform dependent, and one can argue that a truly portable WASI implementation should not leak this information.

The implication of the 16 TiB behavior is that this issue is not just a matter of the range of s64. Maybe WASI should specify a maximum file size. Practically speaking, like @sunfishcode suggested, it may well be much lower than i64::MAX.