On 09/12/17 15:40, James E. King, III via Boost wrote:
Hi folks,
It looks like the only reason boostorg/random is not a header-only library is due to random_device (it is the only src/ file: https://github.com/boostorg/random/tree/develop/src). The older WinCrypt calls are not available in some Windows platforms going forward, so this is going to become a problem pretty quickly for the community.
In the boostorg/uuid library there is a seed_rng class which is doing similar things (however providing more entropy) and the library is header-only. In addition there are two filed defects - one in Trac and one in github issues, about uuid being incompatible with UWP applications (that's Windows universal apps). In uuid, I started adding support for BCrypt which is a Windows API supported on later versions of Windows, and once I changed my build flags to target Windows 10 and WINAPI_FAMILY_APP, I started getting build failures in random_device.
On further inspection it looks like the random library doesn't have support for BCrypt yet, and even worse as a source library one would need to build two variants - one for WinCrypt and one for BCrypt to support older and newer windows platforms. There are also some implications on MinGW, as the older original MinGW has support for WinCrypt and MinGW-64 supports both.
I'm going to propose that the implementation from boost::uuids::detail::seed_rng be moved into boost::random as the new random_device implementation. At the same time, boost::random will become header-only, and thus support setting _WIN32_WINNT at build time of consuming applications properly, and therefore support new Windows platforms properly.
At the same time I would like to change seed_rng such that it no longer silently ignores some return values, and does not disable any compiler warnings (deprecations, currently).
Thoughts?
I think that making Boost.Random header-only would be good. In addition I would suggest adding support for getrandom() on Linux and getentropy() on OpenBSD, as they are protected from file descriptor exhaustion. This can be done in a separate PR though. You will likely need to add BCrypt API to Boost.WinAPI - please, make a PR to it as well.