| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
Made with https://crates.io/crates/typos-cli
|
| |
|
|
|
|
|
|
|
|
| |
- Replaced single quotes in [`hashx::rand`] documentation link to
[`hashx::rand::RngBuffer`] with backticks so it actually works.
- Added a missing backtick to the link to
[`tor_persist::state_dir::StateDirectory::instance_peek_storage`] in the
documentation of
[`tor_persist::state_dir::StateDirectory::with_instance_path_pieces`].
|
| |
|
|
| |
- `try_fill_bytes()` is no longer a member of RngCore.
|
| |
|
|
|
|
| |
Making a few comment tweaks suggested in review feedback.
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
|
|
This refactors the random number generator used within HashX's program
generator so that it uses the rand::RngCore trait. The basic SipHash
powered u64 generator now implements RngCore, while a buffer layer
wraps this and provides u8 and u32 values as needed by the generator.
Some of this new RngCore layer is now exposed to the hashx crate's
public API. The intent is to allow external code to test, benchmark, or
fuzz the program generator by supplying its own random number stream.
Benchmarks show a small but confusing performance improvement
associated with this patch. About a 2% improvement in generation.
This could be due to the Rng changes. No change in compiled hash
execution performance. Even though this patch only touches program
generation, benchmarks show a 4% speedup in interpreted execution.
This seems most likely explained by instruction cache effects,
but I'm not sure.
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
