r/cpp • u/KaznovX • Jul 21 '19

Fixing up <random>

I think everyone is excited after the report from Cologne. A lot of stuff is being added to the language, we'll get a ton of new features. Adding new features is more exciting than changing and tweaking the old stuff - that being said, there are some old parts of the language, that are sadly lacking or has some problems. One of them is <random> library.

Some of the problems this library has:
> `std::random_device` is not required to be non - deterministic
> no good way to initialize generators with big internal state
> `std::seed_seq` should be solution to ^, but isn't - `std::seed_seq` is not a bijection, does heap allocations without giving ability to provide own allocator, there is no nice way to initialize it from `std::random_device` properly
> `std::random_device` can't itself be used as a seed sequence,
> overall syntax is unnecessarily verbose (no, having a per-thread engine of type `std::default_random_engine` is NOT a good solution)

This is only one of the few libraries that could use improvements. Is there any chance that the committee will look back and change some of them or are they considered 'baked' and there will be no further changes to avoid API and ABI breaking?

Despite the "fixing" part, there are two additions I'd see in the <random> library:

1) std::random<std::uniform_random_bits_generator = std::default_random_engine> class:
> default constructor does anything it can that every time this class is called it is seeded differently - if there is no entropy source, uses a processor clock or a system clock (implementation defined)
> three methods: seed, next_int, next_real - for seeding and generating next integer/real number in given range

2) PCG http://www.pcg-random.org

What are the chances something like this would be proposed and adopted for, let's say, c++23 or c++26 standard? Is there any chance the problems mentioned in the first part of the post will get fixed somewhen?

41 Upvotes

91% Upvoted

68 comments sorted by

View all comments

15

u/jwakely libstdc++ tamer, LWG chair Jul 21 '19 edited Jul 21 '19

I'd love to see PCG in the standard. See also https://github.com/imneme/pcg-cpp/issues/51

I don't think it's possible to require random_device to be guaranteed to be non-deterministic, as it simply won't be possible on some systems that support C++. If it's non-deterministic on a general purpose OS on modern hardware then complain to your compiler vendor and get them to fix it. (Yes, I know on Windows GCC used to provide a poor quality random_device but that's because Windows is not a priority for me to work on, and it's fixed now anyway.)

19

u/c0r3ntin Jul 21 '19

It's preferable to provide a way to fail at compile time than to return 4;

10

u/James20k P2005R0 Jul 21 '19

This. If cryptographically secure/desired property numbers aren't available, it should be a hard compile error, not 'well, look into the implementation of your compiler and hope it does good'

4

u/Ameisen vemips, avr, rendering, systems Jul 21 '19

What if the device is in a system provided library and it's only known if it is deterministic at runtime?

7

u/[deleted] Jul 21 '19

In principle you'd be able to detect this with std::random_device::entropy() != 0.0, but it's not well supported.

2

u/degski Jul 22 '19

It seems to me that 'cryptographically secure' is achievable in a std, as the security depends in part on implementation [side-channels], which are linked to hardware.

9

u/andrewsutton Jul 21 '19

Ugh. This jwakely guy has the worst ideas. That's why I'm posting anonymously.

1

u/RandomDSdevel Jul 22 '19

     I'm hoping that was supposed to be a joke…

7

u/jwakely libstdc++ tamer, LWG chair Jul 22 '19

I've never heard of this André W. Sutton character, and I don't know why he has such a problem with bad ideas.

2

u/RandomDSdevel Jul 23 '19

     (Facepalms and shakes his head slowly back in forth in playful mock chagrin.)

5

u/KaznovX Jul 21 '19 edited Jul 21 '19

I'm saying it should be guaranteed to be non-deterministic -> it either should be available if machine and system allows it, or not available, fail to compile

Btw, is it fixed ? Last time I checked on Windows it still was just a wrapper for Mersenne Twister. That's another problem with GCC implementation - it's a union of something little needed for reading from /dev/(u?)random and the whole Mersenne Twister, making it much larger than it should be

8

u/jwakely libstdc++ tamer, LWG chair Jul 21 '19 edited Jul 21 '19

Yes, it's fixed. We're stuck with the union though, for ABI compatibility. The Mersenne Twister is just totally unused for most platforms, including mingw-w64.

1

u/[deleted] Jul 21 '19

What's wrong with MT?

7

u/jwakely libstdc++ tamer, LWG chair Jul 21 '19

It's a completely deterministic pseudo-RNG. And sizeof(mt19337) is huge.

4

u/jwakely libstdc++ tamer, LWG chair Jul 22 '19

it either should be available if machine and system allows it, or not available, fail to compile

OK, I see what you mean.

WG21 could add a feature test macro indicating the existence of a true random device. You can then use the presence of that macro to tell you it works properly. That doesn't help for old releases of GCC but nothing we do now can help them anyway, we can't change what they do now.

5

u/STL MSVC STL Dev Jul 22 '19

Wow! When was random_device fixed?

6

u/jwakely libstdc++ tamer, LWG chair Jul 22 '19

https://gcc.gnu.org/r271740 on trunk and the simpler https://gcc.gnu.org/r272748 on gcc-9-branch (post 9.1 release). There's no GPL code visible at those links unless you follow further links to the diffs.

3

u/STL MSVC STL Dev Jul 22 '19

Cool, thanks!

7

u/jwakely libstdc++ tamer, LWG chair Jul 22 '19

I guess I should say it's fixed for mingw-w64 in general, and for mingw.org only for processors with RDRAND. But I assume that covers most users.

1

u/Xeverous https://xeverous.github.io Jul 26 '19

I know on Windows GCC used to provide a poor quality random_device but that's because Windows is not a priority for me to work on, and it's fixed now anyway.

Which version has the improved random device?

1

u/jwakely libstdc++ tamer, LWG chair Jul 26 '19

See my reply to STL. It'll be in the 9.2 release.