Not only it makes the two implementations equivalent, it also fixes the bug
of to_string throwing an exception in the noexcept function. It is also
more efficient as there is no need for the temporary string construction.
Since getentropy is implemented via getrandom in Linux kernel, getentropy
cannot work if the kernel doesn't support getrandom. Given this, there is
no reason to ever use getentropy on Linux.
We used to allow this backend based on glibc version check, but there are
configurations where a newer glibc is running with an older kernel, and
getentropy always fails in runtime. Disabling getentropy in such cases
allows to fall back to the generic POSIX backend.
Mark function only consisting of a BOOST_THROW_EXCEPTION statement as
BOOST_NORETURN.
According to [0], "Callers of throw_exception are allowed to assume
that the function never returns", and the two predefined versions are
marked with BOOST_NORETURN.
[0] https://www.boost.org/doc/libs/1_69_0/libs/exception/doc/throw_exception.html
Android supports getrandom and getentropy functions only since API version 28.
As part of the fix converted Linux/Android platform detection from Boost.Predef
to direct checks of platform-specific macros. This is to work around
Boost.Predef problem described in [1] - depending on header inclusion order
Boost.Predef may indicate Linux or Android. When that problem is fixed we
may change back to Boost.Predef.
Fixes https://github.com/boostorg/uuid/issues/76.
[1]: https://github.com/boostorg/predef/issues/81#issuecomment-413329061
getrandom is the base implementation for getentropy on Linux. It is also
available in the form of a syscall, which can be called directly on systems with
glibc versions older than 2.25 which don't yet provide wrappers for getrandom or
getentropy but have a recent enough Linux kernel (for example, Debian Stretch).
On systems other than Linux (e.g. Solaris) getentropy is documented as a
source for initialization of a user-space PRNG instead of a direct source
for random data. Since we use the random data directly to initialize UUIDs,
using getrandom on other platforms, where available, would be more preferable
than getentropy. Unfortunately, the only other platform that is known to support
both getentropy and getrandom (Solaris) documents getrandom to return 0
on error, which is a valid return value on Linux. It's not clear if this is
a documentation error or a true incompatibility, and I have no way to test,
so do not use getrandom on Solaris for now. For this reason (and in case
if it is also used on some other platforms) getentropy backend is still
preserved.
For running tests in the CI on the getentropy backend added the
BOOST_UUID_RANDOM_PROVIDER_DISABLE_GETRANDOM macro, which will disable getrandom
if one is detected. Currently, the macro is only used for tests on Linux.
The commit adds support for move constructors and assignment to random UUID
generators and random providers. Also, in POSIX random provider, the commit
improves handling of return value from ::read(), which returns -1
in case of error and may return 0 in case of success. Retry the call when
it was interrupted before reading any bytes from /dev/urandom.
Added new tests for movability and compile-fail tests for no copyability.
This addresses GitHub issue:
https://github.com/boostorg/uuid/issues/71
operating-system provided entropy as it is more secure and
faster for the typical use case of generating one uuid at
a time.
This is a breaking change for anyone passing a mt19937
into one of the explicit constructors of random_generator,
which would be quite rare.
Changed the default random provider on Windows to use BCrypt
where available, falling back to Wincrypt when necessary or
when explicitly requested through a macro.
Provide a new random_generator_mt19937 type definition for
use cases where a large number of uuids need to be created
with high performance. This is equivalent to the previous
definition of random_generator.
Provide a random generation benchmark test showing the
cutoff where the mt19937-based generator will outperform the
standard generator based on wall time.
Removed template specialization for boost::random::random_device
so that any UniformRandomNumberGenerator can be used properly
with random_generator.
Replaced the seed_rng detail implementation (which had a number
of flaws) with a replacement header-only random_provider
implementation.
Note: entropy generation errors will cause an entropy_error
to be thrown from random_generator. The previous implementation
ignored errors and silently failed.
Added internal support for entropy generation on cloudabi
platform leveraging the new random_provider implementation.
Added internal support for Universal Windows Platform (UWP)
development leveraging the new random_provider implementation.
Added internal support for getentropy() on Linux and OpenBSD
if certain requirements are met.
This fixes#24
This closes#53
throw std::runtime_error like it always had before
therefore removing a breaking change before release
remove one unnecessary code branch in string_generator
and provide backwards compatibility for sha1, and also added
md5 to complete the RFC 4122 spec implementation
as such, boost::uuids::name_generator is deprecated, however
still defined to use the same implementation in previous boost
releases, and name_generator_sha1 as well as name_generator_md5
now exist, in preparation for whatever will replace sha1.
to properly test the new header structure, I took the bjam
rule from winapi to isolate each header as an include and make sure
it has no dependencies on other headers to be included first,
and was able to remove a few test files that became unnecessary.
This fixes#26
11483: uuid string generator now throws std::invalid_argument instead of std::runtime_error on an invalid uuid string
12253: make the uuid parser reject invalid data and added negative test cases to prove it
The defect https://svn.boost.org/trac/boost/ticket/11385 reports a
situation where a uuid's single-hex-digit values are improperly padded
when std::left is set on the stream.
It is fixed by ensuring that the ostream overload always uses std::right
to be consistent with the default behavior.
