[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH] Implementations of random, srandom, initstate, setstate, rand, s
From: |
Richard W.M. Jones |
Subject: |
[PATCH] Implementations of random, srandom, initstate, setstate, rand, srand |
Date: |
Thu, 23 Oct 2008 17:11:49 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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
- [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand,
Richard W.M. Jones <=