Open Userzxcvbvnm opened 2 weeks ago
Wasmtime considers the entire space of u32 numbers as valid file descriptors for preview 1, so the renumber to -1
is a renumber to 4294967295
. I don't think this is a bug. It is still possible to show the call to open
failed because the WASI fd_open
interface (implements open
inside libc) has a distinct way to return the failure vs successfully opening fd 4294967295
.
Test Case
The c test case is:
Steps to Reproduce
(1)compile to wasm:
./wasi-sdk-21.0/bin/clang --target=wasm32-unkown-wasi --sysroot=./wasi-sdk-21.0/share/wasi-sysroot test.c -o test.wasm
(2)Running wasm: (Before run the Wasm file, file softfile_3, subdir_1/subdir_2/subfile_1 and subdir_2/subdir_1/subfile_1 exists, and softfile_3 is softlink file points to file subdir_2/subdir_1/subfile_1. Before run the Wasm file, change the permission of subdir_1/subdir_2/subfile_1 into 0200(-w-------) . )
wasmtime run --dir=. test.wasm
Expected Results
Print:
This is what WAMR and WasmEdge do.
Actual Results
wasmtime prints:
Since the permission of subdir_1/subdir_2/subfile_1 is 0200, which only contains write permission, and subdir_1/subdir_2/subfile_1 is opened with O_RDONLY, getting the file descriptor of subdir_1/subdir_2/subfile_1 failure is expected. However, getting the file descriptor of subdir_1/subdir_2/subfile_1 fails, but renumbering file descriptors succeed.
Versions and Environment
Wasmtime version or commit: 19.0.2 and 13.0.1 Operating system: Ubuntu 20.04 Architecture: x86_64