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

[Bruno Haible]

Hi,

Richard W.M. Jones wrote:
> This patch adds a 'random' module which implements:
> 
>   - random
>   - srandom
>   - initstate
>   - setstate

This is welcome!

> and replaces:
> 
>   - rand
>   - srand
>   - RAND_MAX

It shouldn't do that. The random/srandom/initstate/setstate and
rand/srand/RAND_MAX facilities are unrelated. See
  <http://www.opengroup.org/susv3/functions/random.html>
  <http://www.opengroup.org/susv3/functions/rand.html>

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

RAND_MAX is unrelated to 'random' and 'random_r'. POSIX says that the upper
bound for these two functions is 2^31-1. The glibc manual says that RAND_MAX
is the upper bound for random and random_r, but this statement is only valid
for glibc, since in glibc RAND_MAX = 2^31-1.

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

This is fine. We don't think much about multithread-safety at this
point.

> diff --git a/doc/posix-functions/rand.texi b/doc/posix-functions/rand.texi
> index 8b2090f..aecfb10 100644
> --- a/doc/posix-functions/rand.texi
> +++ b/doc/posix-functions/rand.texi
> @@ -4,10 +4,12 @@
>  
>  POSIX specification: @url{http://www.opengroup.org/susv3xsh/rand.html}
>  
> -Gnulib module: ---
> +Gnulib module: random
>  
>  Portability problems fixed by Gnulib:
>  @itemize
> address@hidden
> +Provides a high quality PRNG on all platforms.
>  @end itemize
>  
>  Portability problems not fixed by Gnulib:

If you want to provide an override for the rand() function, it should IMO
  1. not be automatically enabled by the 'random' or 'random_r' modules,
  2. explain in the doc what you mean by not "high quality" of some
     implementations (a period less than 2^32? lower bits that are easy to
     guess?), and which implementations are affected.

Bruno