Re: require et random_device for cons token test

[Jonathan Wakely <jwakely@redhat.com>]

On 25/03/21 07:17 -0300, Alexandre Oliva wrote:
>On Mar 24, 2021, Jonathan Wakely <jwakely@redhat.com> wrote:
>
>> This works for me on x86_64-linux and powerpc64le-linux, and also on
>> x86_64-linux when I kluge the config macros so that the new code path
>> gets used. Does this work for VxWorks?
>
>Thanks.  I (trivially) backported it to apply on our gcc-10 tree, and
>tested that on x86_64-vx7r2, and I confirm it works there too.
>
>However, I suspect there's a series of typos in the patch.  You appear
>to be using the 'which' enum variable for bit testing, but with '|'
>rather than '&'.

Oops, that's what I get for a last-minute rewrite without proper
testing. I originally had:

   if (which == blah || which == any)

and then borked it in an attempt to use & instead.

I'll fix that locally too.

>Unless I'm missing something in my reading of the modified code, this
>may cause a backend different from that requested by the token to be
>selected, but it doesn't look like we have any test that detects this
>problem.

I don't see how it's possible to detect, without something like a
modified system that replaces /dev/random with a non-random source so
you can verify that std::random_device("/dev/random") and
std::random_device("rdseed") don't use the same source.

I suppose we could check the number of open file descriptors as a proxy
for "something is reading /dev/random", but there's no way to check
that std::random_device(tok1) and std::random_device(tok2) use
different sources of randomness.