random, srandom, and initstate

Jeff Johnston jjohnstn@redhat.com
Tue Jun 1 08:35:00 GMT 2010


On 05/31/2010 05:01 AM, Corinna Vinschen wrote:
> On May 31 10:36, Corinna Vinschen wrote:
>> On May 19 13:40, Joel Sherrill wrote:
>>> (2) Should I go ahead and modify them to be
>>>      the _r versions and have the non-_r version
>>>      call those with static variables?
>>
>> Yes.  [...]
>
> Or, maybe not.  Full reentrancy would require to have not only a couple
> of additional scalar variables in reent, but also to keep the randtbl
> array reentrant.  That's kind of a lot of stuff.
>
> Jeff, what do you think?
>

Assuming we are talking about the glibc _r versions which take a struct 
random_data pointer...

The _r routines will use the struct.  AFAICT, the state pointer points 
to an allocated array so modifying the data is ok.

The reent struct should have the struct added.  It will need allocation 
and initialization for small reent platforms.  The non _r routines will 
call the _r routines and pass the struct random_data pointer from 
_REENT.  There should be no static data.

Using the _REENT struct will make it so that automatic reentrancy will 
just work using the __getreent system in libc/include/sys/reent.h (i.e. 
each thread will get/use its own struct random_data under the covers).

Make sense?

-- Jeff J.

>
> Corinna
>



More information about the Newlib mailing list