Mark McCaskey

Thanks for filing the issue and being comprehensive in covering the different pieces! Good feedback is very valuable! I agree very strongly with the premise that we should improve the...

> I've been looking into this by starting to prototype a bit. I first created a proc macro that parses the witx and creates "native" representations of the WASI types....

Sounds good! > That would be the next step. I'd look into having WasiFd, WasiFile and WasiDirectory traits (probably) which encode all constraints in the type system: The original design...

Hmm, so it seems that atomics and non-atomics interact poorly in that there are pretty much no guarantees at all. But we can use a relaxed atomic memcpy from the...

@aidanhs Thanks for the interest! Yeah, our system is set up to be pretty flexible unfortunately there's a lot of inherent complexity in the WasiFs so it might be a...

WASI is definitely its own thing and the libc does do an emulation of a subset of the types of things you might expect to work on a filesystem, but...

Thanks for the reports in regards to the framebuffer! It looks like in this case, it should be fixable by using `pwrite` or `seek` after you write. The framebuffer is...

Perhaps the behavior is not intuitive and should be documented better somewhere!

In regards to the crash, I believe that's due to the `unwrap`! the write calls should be returning an error indicating that the end of the file has been reached...

That's correct! That is the correct behavior and that is what usually happens. However the current implementation is a bit hacky and doesn't support that access pattern because the file...