Using with neither `compile-time-rng` or `runtime-rng` features. about ahash

[tkaitchuck]

Yes. This is the major API change in the 0.8 release. Previously it attempted to look at the OS / Flags to infer when getrandom was available and use it. In 0.8 it no long does this and simply leaves it up to the feature flags. This was done because the automation logic proved inconvenient for some applications.

If neither runtime-rng or compile-time-rng is set, then there are no random constants available as base value so instead of relying on RandomState::new() which uses these random fixed constants RandomState::generate_with() is available so that the application may provide such values directly. (Note that the values passed to generate_with may be fixed constants, and it will still result in different states each time.)

In terms of security strength runtime-rng is obviously best followed by compile-time-rng. But the flag runtime-rng will implicitly disable compile-time-rng. So if you have a library that needs to work in a no-std environment that does need DOS resistance, then depending on compile-time-rng is reasonable because if an upstream application enables runtime-rng it will use the runtime, and the compiled output will be constant as normal. If anything beyond minimal DOS resistance is not required then just pass fixed keys into generate_with and you will get the same behaviour as it had in 0.7.

[Anders429]

Thanks for the explanation. The main cause for my question was use in no-std environments. I initially assumed that I ought to use the runtime-rng feature, but that didn't work in my no-std environment test. I wasn't sure if compile-time-rng was what I wanted, since it wasn't enabled when I was using 0.7. Your explanation was very helpful. I was able to get things working the way I wanted with the compile-time-rng feature.

For the record, I like this change in the new version. It's good for me to actually think about what the hasher is doing when I'm using it.