[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 12:24:02 +0100 |
"Richard W.M. Jones" <address@hidden> wrote:
> On Wed, Oct 29, 2008 at 11:22:08AM +0100, Jim Meyering wrote:
> [random, random_r, RAND_MAX]
>> 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.
>
> This is for a putative platform which has random (and of course
> RAND_MAX) but not random_r. random_r must return random numbers in
> the range [0..RAND_MAX-1] where RAND_MAX is defined by the platform,
> but may not be the same as the RAND_MAX expected by the gnulib code.
>
>> 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.
>
> That's a different API from the one described by the glibc
> documentation ...
Hi Rich,
In this case, that may not be a big deal, since no other system I know of
provides random_r, and considering how I found no documentation that the
random_data.state member must be initialized to NULL before calling
initstate_r. E.g., this works fine:
int
main ()
{
char b[128];
struct random_data r = {.state = NULL };
initstate_r (1, b, sizeof b, &r);
return 0;
}
But if you remove the initialization of r.state, you lose when
initstate_r dereferences it.
The documentation only hints at this by saying that
initstate_r "uses and modifies the state in" that buffer.
All that to say that just because glibc documentation says something
(i.e., it requires the random_r functions to be like the random ones
modulo the state arg) needn't preclude a change like this.
However, if anyone can think of a better way,...
On the other hand, I don't feel very strongly about keeping
random and random_r separate, so if you think making them
into a single "random" module is the way to go, I won't object.
- [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, 2008/10/29
- Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand, Richard W.M. Jones, 2008/10/29
- Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand,
Jim Meyering <=
- Prev by Date:
Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand
- Next by Date:
Re: [PATCH] New module rand48 [rebased]
- Previous by thread:
Re: [PATCH] Implementations of random, srandom, initstate, setstate, rand, srand
- Next by thread:
[PATCH] New module rand48
- Index(es):