Skip to content

OsRng run-time failure / the rand_os crate / modularity #681

Closed
@dhardy

Description

@dhardy

Roughly, rand could be modularised as follows:

component dependencies
rand_core
PRNG crates core
rand_os core + std
JitterRng core + std
EntropyRng core + os + jitter + std
ThreadRng core + os + jitter + entropy + std + hc
seq core
distributions core
Rng core + seq + distributions

Roughly 30% of the current code comes under non-linear distributions, which is its own story (#290). For the rest I don't think there's sufficient utility for more crates.

I regret accepting #643 as-is; it "promises" to support all std platforms yet fails on WASM with a compile error (#674, #678) and on any unsupported platforms. The reasons that is an issue are convoluted (probably involving users depending on rand with default features yet not needing them all), but the conclusion of #678 is that Rand should always build for wasm32-unknown-unknown, failing if necessary at run-time.

We used to use run-time failure within EntropyRng but disable OsRng at compile time where unneeded. Practical solutions are:

  1. Restore the old behavior: rand_os must compile but without the OsRng struct on unsupported platforms. EntropyRng is currently available on all platforms but with run-time failure when no source is available, however it requires a complex cfg pattern in order to disable the missing OsRng dependency when not available; it would therefore make sense to have this in the same crate.
  2. Enable OsRng on WASM, and use run-time failure on missing implementation.
  3. Enable OsRng on all platforms, and use run-time failure on missing implementation.

I think the cleanest solution would be (1), but @tarcieri @naftulikay I understand there would be resistance to moving JitterRng into rand_os. Is this really justified? I guess in part this depends on whether the RFC proposed in #648 gets accepted, though this will be a while coming.

Otherwise we can do (2) or (3); the difference is that (2) would cause build failures on any platform where Rand is used with std/default features but OsRng is unavailable. I'm not sure whether this is a good idea?

I suppose (2) is most sensible now.

CC @newpavlov @burdges

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions