I have observed on Linux writing and reading the same file many times
without the mtime changing, despite the file system having nanosecond
granularity (and about 1 millisecond worth of nanoseconds passing between
modifications). I am calling this a Linux Kernel Bug and adding file
size to the cache hash manifest as a mitigation. As evidence, macOS does
not exhibit this behavior.
This means it is possible, on Linux, for a file to be added to the cache
hash, and, if it is updated with the same file size, same inode, within
about 1 millisecond, the cache system will give us a false positive,
saying it is unmodified. I don't see any way to improve this situation
without fixing the bug in the Linux kernel.
closes#6082
* Implemented all R-type arithmetic/logical instructions
* Implemented all I-type arithmetic/logical instructions
* Implemented all load and store instructions
* Implemented all of RV64I except FENCE
I empirically observed mtime not changing when rapidly writing the same
file name within the same millisecond of wall clock time, despite the
mtime field having nanosecond precision.
I believe this fixes the CI test failures.
Functions which are free'd are not immediately removed from the binary
as this would cause a shifting of function indexes. Instead, they hang
around until they can be overwritten by a new function. This means that
the types associated with these dead functions must also remain until
the function is overwritten to avoid a type mismatch.
Exports now have a dirty flag and are rewritten on flush if this flag
has been set.
A couple other minor changes have been made based on Andrew's review.
Thus far, we only generate the type, function, export, and code
sections. These are sufficient to generate and export simple functions.
Codegen is currently hardcoded to `i32.const 42`, the main goal of this
commit is to create infrastructure for the container format which will
work with incremental compilation.
* Factor redundant code in std/crypto/chacha20
* Add support for XChaCha20, and the XChaCha20-Poly1305 construction.
XChaCha20 is a 24-byte version of ChaCha20, is widely implemented
and is on the standards track:
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
* Add support for encryption/decryption with the authentication tag
detached from the ciphertext
* Add wrappers with an API similar to the Gimli AEAD type, so that
we can use and benchmark AEADs with a common API.
