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_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.

Reply via email to