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

[Jim Meyering]

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