[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Implementations of random, srandom, initstate, setstate, ran
From: |
Jim Meyering |
Subject: |
Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand |
Date: |
Wed, 29 Oct 2008 11:22:08 +0100 |
"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.
- [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand, Richard W.M. Jones, 2008/10/23
- Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand,
Jim Meyering <=
- Prev by Date:
[PATCH] New module rand48 [rebased]
- Next by Date:
Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand
- Previous by thread:
[PATCH] Implementations of random, srandom, initstate, setstate, rand, srand
- Next by thread:
Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand
- Index(es):