Open sunfishcode opened 5 months ago
Most implementations today appear to use inval
.
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
.
The
filesize
type is defined as unsignedu64
. In POSIX,off_t
is a signed type.Most practical implementations won't support file sizes >= 263, 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 toinval
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 useinsufficient-space
?