Path bytes returned from wasi::fd_prestat_dir_name appended by 0

[Mo-Fatah]

Describe the bug

I used this wasi crate to compare the behavior of WASI implementations between wasmtime and wasmer.
Initially, I used wasi::fd_prestat_get and wasi::fd_prestat_dir_name .

Apparently all path/dir/file names (in bytes) returned from fd_prestat_dir_name are appended by 0.

I am using

wasmer 2.3.0 | rustc 1.61.0 (fe5b13d68 2022-05-18) | x86_64

Steps to reproduce

I wrote a simple program here that prints either wasmer or wasmtime based on the directory name returned from fd_prestat_dir_name.

1- The program takes an environment variable which is the directory name , this will be arg

2- Then, I used fd_prestat_get and fd_prestat_dir_name to access the directory passed to the engine through WASI interface which will be stored in dst variable.

3- I compared the dir name bytes which passed to the program (arg) against the name bytes returned from the WASI interface
https://github.com/Mo-Fatah/wasi-testsuite/blob/13ccd4d9ebd6d326dcb487ebadf2917088c07223/engines-diff/end-of-path/src/main.rs#L37-L46

Expected behavior

Assuming that the directory name is scratch_dir and it is located in the root of the program.

• Executing with wasmtime by
  wasmtime --dir scratch_dir ./target/wasm32-wasi/debug/end-of-path.wasm scratch_dir
  the arg bytes and dst bytes will be exactly the same (as they should be)

arg: [115, 99, 114, 97, 116, 99, 104, 95, 100, 105, 114]
dst: [115, 99, 114, 97, 116, 99, 104, 95, 100, 105, 114]
Wasmtime used

wasmer should get the exact output

Actual behavior

2- Executing with wasmer by
wasmer run --dir scratch_dir ./target/wasm32-wasi/debug/end-of-path.wasm scratch_dir
the dst variable will be appended by0

arg: [115, 99, 114, 97, 116, 99, 104, 95, 100, 105, 114]
dst: [115, 99, 114, 97, 116, 99, 104, 95, 100, 105, 114, 0]
Wasmer used

Additional context

I am testing wasi implementation of different engines. I started with wasmtime and wasmer and I noticed this behavior from wasmer which I assume not correct.

[syrusakbary]

This indeed seems like a bug and we should fix it. Thanks for creating the issue!

[syrusakbary]

This one is fixed by #3061

[ptitSeb]

Openned a ticket in WASI specs site to get clarity on the behaviour: WebAssembly/WASI#492

[ptitSeb]

@Mo-Fatah the fix is merge in master, you can test and see it's fixed now.