Stream: git-wasmtime

Topic: wasmtime / issue #8068 wasmtime cli only taking the last ...

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:51):

mtobin-tdab added the bug label to Issue #8068.

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:51):

mtobin-tdab opened issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Note: if you want to report a security issue, please read our security policy!

Test Case

Working on creating a test case

Steps to Reproduce

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory but one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:52):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Note: if you want to report a security issue, please read our security policy!

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory but one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:52):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Note: if you want to report a security issue, please read our security policy!

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:54):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Note: if you want to report a security issue, please read our security policy!

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:55):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:55):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can run bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:59):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can run bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

**Note that it is able to read from both if the absolute path is more specific - i.e. if the absolute path is under /home

bin/wasmtime --dir=. --dir=/home target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
will successfully read and print both files

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:59):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can run bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

** Note that it is able to read from both if the absolute path is more specific - i.e. if the absolute path is under /home

bin/wasmtime --dir=. --dir=/home target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
will successfully read and print both files

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:59):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can run bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

** Note that it is able to read from both if the absolute path is more specific - i.e. if the absolute path is under /home

bin/wasmtime --dir=. --dir=/home target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
will successfully read and print both files **

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 14:59):

mtobin-tdab edited issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can run bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Note that it is able to read from both if the absolute path is more specific - i.e. if the absolute path is under /home

bin/wasmtime --dir=. --dir=/home target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
will successfully read and print both files

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 08 2024 at 15:00):

bjorn3 commented on issue #8068:

What is the source code of this wasm module?

Wasmtime GitHub notifications bot (Mar 08 2024 at 15:00):

bjorn3 deleted a comment on issue #8068:

What is the source code of this wasm module?

Wasmtime GitHub notifications bot (Mar 08 2024 at 15:05):

mtobin-tdab commented on issue #8068:

@bjorn3 There is an example in the zip file attached: https://github.com/bytecodealliance/wasmtime/files/14539480/bug_demo.zip

It seems all versions of wasmtime have this issue (I'm using a version of wasmtime 17.0.0 but it is also true for 18.0.2

Wasmtime GitHub notifications bot (Mar 08 2024 at 16:34):

mtobin-tdab deleted a comment on issue #8068:

@bjorn3 There is an example in the zip file attached: https://github.com/bytecodealliance/wasmtime/files/14539480/bug_demo.zip

It seems all versions of wasmtime have this issue (I'm using a version of wasmtime 17.0.0 but it is also true for 18.0.2

Wasmtime GitHub notifications bot (Mar 08 2024 at 16:35):

alexcrichton commented on issue #8068:

Thanks for the report! I think though it's going to be a bit tough to say where the bug is here though. With --dir . and --dir / Wasmtime is configuring the "preopens" with names . and /, as expected. In wasi-libc, however, both of these strings are "normalized" to the empty string.

More-or-less I think the issue you're running into here is that wasi-libc's emulation of the current working directory is a bit buggy in the case of having both . and / preopens. In this case wasi-libc doesn't know what the current working directory is so the "loose convention" so far of both of those being somewhat equivalent to the current working directory clashes and then things don't work.

I believe that the fix for this is going to be in wasi-libc, not Wasmtime. I don't know of the best way to fix it there, though, as writing path-handling code in C is not my personal forte at least.

Wasmtime GitHub notifications bot (Mar 12 2024 at 11:14):

mtobin-tdab commented on issue #8068:

Thanks for this, very helpful! I will make an equivalent issue in the wasi-libc repo.

Wasmtime GitHub notifications bot (Mar 26 2024 at 03:15):

alexcrichton closed issue #8068:

I appear to be finding that wasmtime version 17.0.0 does not handle --dir=/ --dir=.

I have tried different combinations of

--dir=. --dir . --dir .::.
--dir=/ --dir / --dir /::/

But am finding that whichever is passed first not working as expected (i.e. files cannot be found through that file descriptor)

Is this a known limitation? I am running wasmtime in a docker container and my goal is to allow it access to all files on the container as well as the current directory (in order not to have to change file paths)

I am using cargo component build --release to build the project

Test Case

Here is a small project which will reproduce the issue:
bug_demo.zip

• The binaries are included so you can run bash run-test.sh from inside the directory to run the test
• You can also rebuild with cargo component build --release
• The project tries to read from two files, both in the same directory - with one referred to relative to the current directory and one with an absolute path (This is passed as an arg using ${PWD} so the absolute path relative to your machine will be used)
• Two wasmtime commands are run:
  • bin/wasmtime --dir=/ --dir=. target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
  • bin/wasmtime --dir=. --dir=/ target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
• Note that only the order of --dir args is different, however the outputs are respectively:

Error reading file: No such file or directory (os error 44)
Reading file: ./file2.txt...
--dir=. worked

Reading file: /home/mtobin/projects/OctaiOxide/bug_demo/file1.txt...
--dir=/ worked.
Error reading file: No such file or directory (os error 44)

Note that it is able to read from both if the absolute path is more specific - i.e. if the absolute path is under /home

bin/wasmtime --dir=. --dir=/home target/wasm32-wasi/release/bug_demo.wasm ${PWD}/file1.txt
will successfully read and print both files

Expected Results

It should read and output content from both files

Actual Results

Depending on the order or dir args, runtime is able to locate one or the other

Versions and Environment

cargo component 0.8.0

Wasmtime version or commit: 17.0.0
(wasmtime binary I am using is in the zip file attached above)

Operating system: ubuntu20

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 26 2024 at 03:15):

alexcrichton commented on issue #8068:

Closing in favor of https://github.com/WebAssembly/wasi-libc/issues/484 as I believe this is a wasi-libc issue

Last updated: Nov 22 2024 at 16:03 UTC