[PATCH] Implementations of random, srandom, initstate, setstate, rand, srand

[Richard W.M. Jones]

This patch adds a 'random' module which implements:

  - random
  - srandom
  - initstate
  - setstate

and replaces:

  - rand
  - srand
  - RAND_MAX

It depends on the 'random_r' module.

random vs random_r
------------------

It has to be said that while it is nice to have separate 'random' and
'random_r' modules, their intimate dependence on the shared RAND_MAX
constant makes that hard to support.

For example, if a platform has RAND_MAX defined to some value which
isn't 2147483647, and the Gnulib user pulls in 'random_r' but not
'random', then they will see unexpected values returned from either
random() or random_r().  Either we override RAND_MAX with 2147483647,
or we leave RAND_MAX at the platform constant, but one way or the
other the platform random() or the Gnulib random_r() will return
values out of the expected range.

So I think long term the only supportable solution is to fold
'random_r' functionality into one big 'random' module that replaces
everything or nothing.

On Windows, RAND_MAX is defined as 0x7fff, platform rand() returns
values in this range, and they have a reputation for not being very
random.  (It appears Windows offers a separate CryptoAPI if you really
wanted random numbers).

Locking
-------

As seems to be traditional with gnulib, I've removed the glibc
locking.  cf. setenv and related modules.  Strictly speaking this is a
violation of POSIX, since rand() is supposed to work even when called
in parallel from multiple threads.  (It currently _won't_ work if you
try this - I expect you'll get strange corruption or even crashes).
I'm not sure if gnulib offers any sort of locking.

int32_t & struct random_data
----------------------------

The current implementation of the 'random_r' module doesn't actually
work for me in MinGW.  It's lacking a definition of the random_data
structure.

In glibc this is defined in <stdlib.h> so I did the same thing.
However this has the side effect that we have to include <stdint.h> in
<stdlib.h> in order to get int32_t.  This doesn't seem to be very
nice, but glibc does a similar thing.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

0001--Implementations-of-random-srandom-initstate-set.patch
Description: Text document