On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
On Mar 24, 2021, Jonathan Wakely <jwak...@redhat.com> wrote:
It should be impossible to have no random_device. As a fallback a
pseudo random number generator should be used.
If the default constructor throws then that suggests your target is
misconfigured. Why isn't the mt19937 PRNG being used?
This is an x86_64-vx7r2 target, it has USE_RDRAND and USE_RDSEED both
enabled as the only RAND backends. AFAICT both of them fail their cpuid
tests, so _M_init falls through to the default, and throws.
I suppose we need to cover the case in which all of the compile-time
presumed-available random backends turn out to not be available at
run-time, and introduce an MT19937 dynamic fallback in the following
default: block, no?
Hmm, that would be tricky because it's currently a static decision
made during preprocessing. We have no disciminator to tell us at
runtime that the _M_mt member of the union is active:
union
{
struct
{
void* _M_file;
result_type (*_M_func)(void*);
int _M_fd;
};
mt19937 _M_mt;
};
Does vxworks provide any platform-specific source of randomness, like
Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes, we
should add support for that (in the next stage 1).
But even if it does, we should still have a dynamic fallback at
runtime. I have a patch coming to do that ...
