random, srandom, and initstate

[Joern Rennecke]

Reviving an old debate because it doesn't seem to have been resolved, and
the issue how make srandom / random available for a port came up with the
Epiphany port...

On May 19 2010, Joel Sherrill wrote:
> Hi,
>
> I have been looking around for an implementation
> to port to newlib.  This is a link to the
> FreeBSD version.
>
> http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libc/stdlib/random.c?rev=1.25.12.1;content-type=text%2Fplain

Maybe we should start with the NetBSD src/common 1.2 version.
This hasn't got srandomdev:
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/common/lib/libc/stdlib/random.c?rev=1.2&content-type=text/plain

This does have locking, though, that would have to be backed out if we
want to convert to reent.  Or modified to use newlib lock acquire / release
names.

Or we could use the FreeBsd version, and split out srandomdev into a
separate file.  Unless we want to use highly nonobvious macro trickery,
we can't use the file(s) unchanged because of the reentrancy issues.

On May 31 2010, Corinna Vinschen wrote:
> On May 19 13:40, Joel Sherrill wrote:
> > (1) It's use of /dev/random and gettimeofday
> >     as possible seed sources can be accomodated
> >     in newlib.  Probably need to be disabled
> >     via some conditional compilation.
>
> I don't think you need to conditionalize them at all.  gettimeofday is
> expected to exist (but see below) and the existence of "/dev/random" is
> tested by the open call anyway.  If it doesn't exist, the srandomdev
> function will use gettimeofday.

It doesn't fit with the philosphy of newlib to let the (static) linker
pull in gettimeofday and standard I/O when you only want srandom and
random.  Hence, srandomdev does not belong in the same library object file.
At the same time, the reason for using a single translation unit - the use
of static variables - should be moot when converting to newlib's reent
data structures.

On May 31 2010, Jeff Johnston wrote:

> The reent struct should have the struct added.  It will need
> allocation and initialization for small reent platforms.

We already have the _rand48 struct there.  Maybe we could have a larger
struct that starts with the _rand48 struct, and then has a flag to indicate if
the random state follows.  Thus we could avoid increasing the size of the
small reent struct.  Actually, we can put that flag before the _rand_next
field, so on targets that align long long more than short, it should take no
extra space.

On Jun 1 2010, Corinna Vinschen wrote:
> However, I just examined the glibc implementation.  The default randtbl
> array is only accessible from the non _r functions and locking just
> allows concurrent threads to use the non-_r random functions in
> parallel.  So my assumption appears to be somewhat over the top.

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.