Re: require et random_device for cons token test

[Jonathan Wakely <jwakely@redhat.com>]

On 24/03/21 07:33 -0300, Alexandre Oliva wrote:
>On Mar 24, 2021, Jonathan Wakely <jwakely@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 ...