On 24/03/21 08:59 +0000, Jonathan Wakely via Libstdc++ wrote:
On 24/03/21 03:53 -0300, Alexandre Oliva wrote:
On target systems that don't support any random_device, not even the
default one,
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
other random_device constructor tests are disabled by
dg-require-effective-target random_device. The token.cc also
exercises the default constructor, in a way that doesn't expect an
exception to be raised, but it's not guarded by the same requirement.
Other potentially-raising ctors in token.cc expect exceptions and
handle them, but the ("default")-constructed one does not, so the
program terminates and the test fails without exercising the other
constructor variants.
Why does the "default" token cause an exception?
This patch arranges to disable the test altogether when the
random_device feature is not available. A reasonable alternative
would be to install a std::runtime_error handler around the test01
body, so that we exercise at least the exception raising, but then
test03 would have to be relaxed, since without even "default", it
likely wouldn't meet the tested requirement there.
Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
with other patches, mostly for the testsuite. Ok to install?
No, that would disable the test for Windows, where it works OK.
The 'random_device' effective-target is poorly named, it checks
whether the _GLIBCXX_USE_RANDOM_TR1 macro is defined, which is even
more poorly named. That macro is defined when /dev/random and
/dev/urandom are available. But we support std::random_device without
those files (e.g. on Windows).
And that macro is defined according to the same conditions as
_GLIBCXX_USE_DEV_RANDOM which is tested via #ifdef in cons/token.cc.
So the test already guards the parts that should depend on the
_GLIBCXX_USE_RANDOM_TR1 macro. Everything else in the test *should*
work unconditionally. In theory. We should find out why they don't
(and probably fix the library code, not disable the test).
Several of the other tests in that directory should *not* require that
effective-target. They should now work unconditionally too.
Tangentially, it would also be good to improve the definition of the
effective-target so it is true for Windows and other targets that are
guaranteed to have a useful (non-pseudo RNG) std::random_device.
