The default implementation of random_device uses /dev/urandom, which may not be available to systems like bare-metals.
This patch adds a CMake option "LIBCXX_ENABLE_RANDOM_DEVICE" to control the build. Default is On.
Differential D41316
[libcxx] Allow random_device to be built optionally efriedma on Dec 15 2017, 4:56 PM. Authored by
Details
Diff Detail Event TimelineComment Actions I keep seeing patches go by for other targets where they're just implementing random_device for their target. It doesn't *have* to be based on an actual /dev/urandom. You can see all the other options under #ifdefs in this file: getentropy, /dev/random, nacl_secure_random, arc4random, rand_s,... If you're on a target that doesn't have any of these, then IMO the appropriate patch would be one of
where the latter provides a "random_device" that yields nothing but zeroes. That would still be very slightly better than providing a non-conforming implementation. (And notice that the useless double random_device::entropy() method will for the first time return a *mathematically correct* value for the always-zero random_device! ;)) Comment Actions I'd much rather provide no implementation than one that lies. Broken builds are much safer than problems at runtime. Comment Actions I say that because there are contexts where it is absolutely critical that https://xkcd.com/221/ not be the implementation of an RNG. Comment Actions Does it make sense to provide an implementation based on C99 rand? srand(0), rand() Comment Actions Should we go with current patch? or provide a srand/rand based implementation as an option? Comment Actions @weimingz: Since your platform supports srand(0), is it possible to look at how your platform implements srand(0) and "inline" that implementation into random_device? That seems like it would be more in keeping with the other ifdefs in this file. I'm confident that constructing an instance of random_device MUST NOT actually call srand. (I'd like to say that it shouldn't even call rand.) Either of those calls would be observable by the programmer. But there is a precedent for e.g. random_shuffle making calls to rand. Comment Actions We can wrap the random_device as a minstd_rand, a linear congruential enginer that a lot of C lib uses for rand(). [1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf section 29.6.6 Class random_device (page 1082) [2]
Comment Actions
You'll need a bunch of UNSUPPORTED: has-no-random-device or something like it, but other than that, I'm happy with the patch as-is. Comment Actions Disable tests that depend on random_device. Comment Actions I think the direction here is OK. Although I really hate allowing bits of libc++ to be "optional". In this case it should be OK, but often it makes the library trickier to maintain -- and these configurations often go untested between releases.
Comment Actions Modified the random generator in filesystem_test_helper to use high_resolution_clock as seed. Comment Actions [rand.device]/2 seems to be the authoritative word here: If implementation limitations prevent generating nondeterministic random numbers, the implementation may employ a random number engine. Comment Actions Yes, the standard says you're allowed to throw an exception from the random_device constructor, or use a PRNG with an arbitrary seed, or even just return zeros from operator(). But none of those behaviors are actually useful; the code will compile, but you won't get the expected randomness. So I prefer this solution, even if it isn't strictly standard-compliant. (I'll post an updated version with the tests fixed soon.) Comment Actions Get rid of the test changes. They were broken in multiple ways, and weren't really useful anyway because the targets where you would want to use this can't run the libcxx testsuite anyway (because they don't have an operating system to run the test programs under). Comment Actions
testsuite anyway (because they don't have an operating system to run the I used to run libcxx tests for an arm baremetal toolchain I was building Jon Comment Actions For those that would prefer random device to not exist if it isn't cryptographically secure, please write a wg21 paper. I will gladly review such a paper, and if you need a presenter, then I will present it if I am attending. I won't be at Rapperswil, but I will be at San Diego. Stated differently, I agree with both Marshall and the other commenters on this page. I don't want busted random_devices to build, AND I want a standards compliant implementation. To some degree, this overlaps with http://wg21.link/P0829 . That (my) paper does not require random_device to exist in a freestanding environment. |
nit: ON