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

[Jim Meyering]

"Richard W.M. Jones" <address@hidden> wrote:
> 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).

Good point.

However, what if an application wants only random_r?
We shouldn't require that they import all of the non-thread-safe
functions, too, so I think random really does belong separate.
Of course, it depends on random_r no matter what.

Perhaps then, random_r should not define RAND_MAX --
define a new symbol, e.g., RANDOM_R_MAX instead.
Then only the random module would define RAND_MAX.


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

People developing multithreaded applications on mingw
will have bigger problems than this ;-) so defining away
locks seems fine for now.