[Chicken-hackers] [PATCH] random returns the same number on x86_64 all the time

[Peter Bex]

Hi!

While looking into the strange behavior found in #793 I found out the
following disturbing fact (ONLY on amd64):

#;1> (random most-positive-fixnum)
-2147483648
#;2> (random most-positive-fixnum)
-2147483648
#;3> (random most-positive-fixnum)
-2147483648
#;4> (random most-positive-fixnum)
-2147483648
..etc..

Turns out that this is caused by an erroneous cast to (int) of
the result value of the division in C_random_fixnum.

Since hash tables use this for a value, I suppose people on 64 bit
platforms who are running the latest master with the hash table
randomization fix (or any other use of random for security reasons
with large fixnums) are still vulnerable until they also apply the
attached patch.


I also saw that C_num_to_int contains a similar cast, but I wasn't
able to trigger an error.  For example, a program with a trivial
foreign-lambda using size_t (which uses num_to_int) seems to
receive the full 64-bit value.  I'm unsure if this is coincidence
or actual correct behaviour we can rely on.  I didn't dare to change
it because I feared I might be breaking other things (a C function
accepting "int" *should* get its arguments truncated to int, and
the FFI also uses C_num_to_int for those types)

Possibly we need to distinguish between C_num_to_int and
C_num_to_size_t or C_num_to_word?

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

0001-Fix-cast-in-C_random_fixnum-so-it-doesn-t-cause-over.patch
Description: Text document