change reopen_with_fdflags(&self, fdflags) -> Result<Box<dyn WasiFile>>
to set_fdflags(&mut self, fdflags) -> Result<()>.
this makes way more sense than my prior hare-brained schemes.
This commit introduces two new methods on `Memory` that enable
reading and writing memory contents without requiring `unsafe`.
The methods return a new `MemoryError` if the memory access
fails.
* need to close the handle to the subdirectory before its legal to
delete it
* windows doesnt give us a way to distinguish between an ERRNO_PERM and
an ERRNO_ACCES, so lets accept either one
* path_open of a directory without OFLAGS_DIRECTORY worked on linux,
but fortunately not on windows!
* the errno is BADF instead of NOTCAPABLE for fd_seek on a directory
* no way for a directory to have the FD_SEEK right.
cargo-deny tells us that we should upgrade raw-cpuid to v9.0.0. This
new version also seems to lack the `nightly` feature (perhaps it has
been incorporated into the base functionality) so I had to remove this
feature selector to build.
* Add support for the experimental wasi-crypto APIs
The sole purpose of the implementation is to allow bindings and
application developers to test the proposed APIs.
Rust and AssemblyScript bindings are also available as examples.
Like `wasi-nn`, it is currently disabled by default, and requires
the `wasi-crypto` feature flag to be compiled in.
* Rename the wasi-crypto/spec submodule
* Add a path dependency into the submodule for wasi-crypto
* Tell the publish script to vendor wasi-crypto
I had missed that the CI config didn't actually run the tests, because
(I think) `matrix.target` is not set by default (?). All of our hosts
are native x86-64, so we can just gate on OS (Ubuntu) instead.
I also discovered that while I had been testing with the gdb tests
locally, when *all* `debug::*` tests are run, there are two that do not
pass on the new backend because of specific differences in compiled
code. One is a value-lifetime issue (the value is "optimized out" at the
point the breakpoint is set) and the other has to do with basic-block
order (it is trying to match against hardcoded machine-code offsets
which have changed).
