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

Previous Next

Full log

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32605: [w64] (random) never returns negative
Date: Sat, 14 Aug 2021 09:31:06 +0100

On Sat 14 Aug 2021, Eli Zaretskii wrote:

>> 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.

Please look at get_random() in sysdep.c: it constructs wider random
numbers by concatenating random bits from calling random() in a loop,
and expects that the result of each call in that loop returns RAND_BITS
(defined in sysdep.c as 31 on this platform).

The random() replacement in w32.c does not meet this contract, as it
only provides 30 bits, causing get_random() to produce a concatenated
result containing bits with fixed, non-random values.

>> > 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.

There doesn't seem to be any point in making changes if they disguise a
bug rather than fixing it. Your proposal just changes which bits in the
the result are non-random.

> 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.

As far as I can see the way to fix this is one of:
a) Fix random() in w32.c to return a 31 bit random number.

b) Modify the logic in sysdep.c that defines RAND_BITS to set it to 30
   on this platform, so get_random() produces working results.
   The get_random() loop would then need one call to random on 32bit
   builds (FIXNUM_BITS is 30), and three on 64bit builds (FIXNUM_BITS is 62).

I'm not an expert on random numbers either, and your efforts are not an
annoyance, but I am puzzled why you so strongly prize performance over
correctness in this instance.

    AndyM

Previous Next

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