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