So C++11 introduced support for random numbers. They actually got it
somewhat right as there is a way to get non-deterministic random
numbers as well as some well-defined potentially deterministic
pseudo-random generator algorithms. And the interfaces are named such
that people will probably use the non-deterministic interface if they
don't know what they're doing.
Looking at the libc++ implementation, we obviously want
_LIBCPP_USING_ARC4_RANDOM. So I'd like to commit the diff below.
Now of course they didn't get it completely right. The random_device
constructor takes an optional "token" argument. Its meaning is
implementation-defined but it is intended to differentiate between
different sources of randomness. And you probably already guessed;
the implementation uses this to perpetuate the /dev/random vs
/dev/urandom distinction. To the defence of the libc++ developers,
they probably did this to be compatible with GNU libstdc++.
Selecting _LIBCPP_USING_ARC4_RANDOM will make the implementation throw
an exception if "token" isn't "/dev/urandom". That might actually be
a good thing, as it will weed non-portable code. But if it turns out
to be a serious issue in ports, we could patch the implementation to
simply always ignore "token".
Index: lib/libcxx/include/__config
===================================================================
RCS file: /cvs/src/lib/libcxx/include/__config,v
retrieving revision 1.2
diff -u -p -U5 -r1.2 __config
--- lib/libcxx/include/__config 5 Sep 2016 18:45:08 -0000 1.2
+++ lib/libcxx/include/__config 19 Sep 2016 11:49:53 -0000
@@ -173,11 +173,11 @@
# define _LIBCPP_LITTLE_ENDIAN 0
# define _LIBCPP_BIG_ENDIAN 1
# endif
#endif // __sun__
-#if defined(__CloudABI__)
+#if defined(__CloudABI__) || defined(__OpenBSD__)
// Certain architectures provide arc4random(). Prefer using
// arc4random() over /dev/{u,}random to make it possible to obtain
// random data even when using sandboxing mechanisms such as chroots,
// Capsicum, etc.
# define _LIBCPP_USING_ARC4_RANDOM
