random, srandom, and initstate

[Corinna Vinschen]

Hi Joern,

On Mar 27 20:46, Joern Rennecke wrote:
> Quoting Joern Rennecke <amylaar@spamcop.net>:
> 
> >Hmm, locking would seriously reduce the class of multithreading scenarious
> >where random can work.  If an interrupt tried to use it while it is already
> >active, deadlock would result - similar to malloc.
> >OTOH it should avoid all the issues in having to change our data structures
> >to support random (3) reentrancy - allowing us to use the NetBSD version
> >with just minor changes.
> >And it should be good enough for gcc.c-torture/unsorted/udivmod4.c and
> >its ilk.
> 
> I've tried an implementation; tested on x86_64-unknown-linux-gnu X sh-elf
> with gcc/testsuite/gcc.dg/vshift-{1,3}.c rolled back to revision 181613 .
> 
> Below is the diff to the NetBSD original, and the second attachment is the
> patch for newlib.
> 
> I'm not sure about random_r / srandom_r : should I add a dummy struct _reent *
> parameter so that the implementation could later/optionally be changed to
> work without locking?

I think this would make sense, even if only for symmetry with the
other reentrant functions.

As for your patch:

- It's missing the declarations in stdlib.h (guarded with __STRICT_ANSI__).

- Why does srandom_r take an unsigned long parameter while srandom
  only takes unsigned int?

Otherwise it looks good.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat