GNU bug report logs - #32605
[w64] (random) never returns negative

Previous Next

Full log

Message #36 received at 32605 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 32605 <at> debbugs.gnu.org
Subject: Re: bug#32605: [w64] (random) never returns negative
Date: Sat, 14 Aug 2021 08:54:53 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Fri, 13 Aug 2021 22:12:29 +0100
> 
> You elided the detail of my previous message:

Because I had nothing useful to say in response.  If someone wants to
work on a better emulation of 'random' for w64, that's fine; I don't
consider myself an expert in this area, and therefore not sure I even
understand the significance of providing 31 bits of randomness from a
functions such as 'random', which AFAIR is not the standard of RNGs.
My goal was to make the current implementation better with relatively
simple and straightforward changes.  Calling rand_as183 one more time
is IMHO not a good solution; but again, I'm not an expert.

> > What about the variant below, does it produce better results?
> >
> >     int val = ((rand_as183 () << 15) | rand_as183 ());
> >   #ifdef __x86_64__
> >     return 2 * val - 0x7FFFFFFF;
> >   #else
> >     return val;
> >   #endif
> 
> Why is this any better ? On 32bit builds it does not return 31 random
> bits (only a 30bit value) and on 64bit builds the lowest bit is not
> random.

I hoped it will be better because it produced negative values as well,
not only positive values, without any performance penalty.  For a
problem that was left unsolved for 3 years it sounds good enough to
me.

So my proposal is to install the above until someone comes up with a
better solution.  But if that's unacceptable, let alone if my
participation in this discussion is an annoyance, like it seems to be,
I'll readily bow out of it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.