Closed sleffler closed 2 months ago
Amanieu
commented
1 year ago Hashbrown doesn't make any guarantees about the hasher and opts for the fastest performance. If you have specific requirements for a random seed then you should use the ahash crate directly.
sleffler
commented
1 year ago Yes, this is not your issue (and thank you for the subtle pointer to the _with_capacity_and_hasher api). I've tracked this down to the latest rev of the const-random crate that ahash depends on--it breaks my no_std usage.
On Mon, Oct 23, 2023 at 4:05 PM Amanieu @.***> wrote:
Hashbrown doesn't make any guarantees about the hasher and opts for the fastest performance. If you have specific requirements for a random seed then you should use the ahash crate directly.
— Reply to this email directly, view it on GitHub https://github.com/rust-lang/hashbrown/issues/478#issuecomment-1776163507, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRM7IP7S4657UHBU4L7OKLYA3Z5HAVCNFSM6AAAAAA6MZHRI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGE3DGNJQG4 . You are receiving this because you authored the thread.Message ID: @.***>
We've been using hashbrown in an embedded environment (no os rng) with:
hashbrown = { version = "0.11", features = ["ahash-compile-time-rng"] }
recent (maybe) changes removed the "ahash-compile-time-rng" feature. The current hashbrown Cargo.toml depends on ahash with:
ahash = { version = "0.8.0", default-features = false, optional = true }
which causes ahash to use fixed entropy to generate keys. I don't see how to configure hashbrown so that it depends on ahash with compile-time-rng? (w/o forking/patching the crate)
Am I missing something?