sunfishcode opened PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode requested kubkon for a review on PR #2046.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
kubkon submitted PR Review.
kubkon created PR Review Comment:
Hmm, why is this cast suddenly needed here?
kubkon submitted PR Review.
kubkon created PR Review Comment:
Ditto.
kubkon created PR Review Comment:
Out of curiosity, what is
l4re
?
kubkon created PR Review Comment:
Do we need to
as
cast here at all?
kubkon created PR Review Comment:
Have you verified this is the case on different BSD flavours perhaps?
kubkon created PR Review Comment:
Is this loop necessary for actual OSes? I thought that
libc::PATH_MAX
existed for a reason and the OS would never return a path that is actually longer, or am I missing something here?On WASI, it makes sense to loop since we AFAIK we don't have the concept of a
PATH_MAX
since it's so platform-dependent and could actually leak what host we're running on, but I'm not sure this loop is at all necessary on actual OSes. Plus, doesn't it lead to unnecessary allocs which could have been easily handled using static buffers instead like it was prior to this change?
sunfishcode submitted PR Review.
sunfishcode created PR Review Comment:
WASI's
RawFd
isu32
.libc::fdopendir
takes ac_int
, which is signedi32
.
sunfishcode created PR Review Comment:
As above,
RawFd
is au32
on WASI.
sunfishcode submitted PR Review.
sunfishcode submitted PR Review.
sunfishcode created PR Review Comment:
It's a microkernel with L4 ancestry. It's just here because I looked that Rust's
libc
crate to see which platforms needed this, and it was one of them.
sunfishcode submitted PR Review.
sunfishcode created PR Review Comment:
Ah, yes. FreeBSD's
readdir
says:The function returns NULL upon
reaching the end of the directory or on error. In the event of an error,
errno may be set to any of the values documented for the getdirentries(2)
system call.The Unix convention for situatuations like this is to set errno to 0 before the call, and check if it's non-zero after the call. POSIX's description of
readdir
makes this explicit:Applications wishing to check for error situations should set errno to 0 before calling readdir(). If errno is set to non-zero on return, an error occurred.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode submitted PR Review.
sunfishcode created PR Review Comment:
For WASI, I want to avoid PATH_MAX because the actual value of PATH_MAX depends on the underlying host OS, so it's better for WASI code to avoid making size assumptions. But you're right that other platforms don't need this. I've now made this code conditional to restore stack allocation.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode updated PR #2046 from yanix-wasi
to main
:
This is a series of patches which begin porting yanix to WASI, and which contain various other fixes needed for using yanix outside of Wasmtime in general.
sunfishcode closed without merge PR #2046.
Last updated: Nov 22 2024 at 17:03 UTC