Open insouciiance opened 1 year ago
Tagging subscribers to this area: @dotnet/area-system-runtime See info in area-owners.md if you want to be subscribed.
Author: | insouciiance |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Runtime`, `untriaged` |
Milestone: | - |
Background and motivation
Currently, certain types & methods use
Interop.GetRandomBytes
(e.g.HashCode
orstring.GetHashCode
) to have a random seed for hash codes, meaning they return different hash for the same value on different program runs.However it would really nice to have the ability to stabilize all hash codes across multiple runs. One use case for this feature would be to detect changes in behaviour on CI and verify if those were intended or not. To have deterministic rendering results we would expect deterministic hash codes so that, for example, enumerating a set or a dictionary is stable (of course no ordering is expected at all, but it should be deterministic).
API Proposal
API Usage
or
Alternative Designs
Risks
Hash code randomization is good for security, prevention against DoS attacks, etc. Having stable hash codes across runs may result in hash flooding, so it needs to be toggled explicitly via the assembly attribute or the .csrpoj property.