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