Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!umcp-cs!gymble!lll-crg!brooks
From: brooks@lll-crg.ARPA (Eugene D. Brooks III)
Newsgroups: net.bugs,net.unix,net.lang.c,net.math
Subject: Re: Re: Bug in rand() and srand()
Message-ID: <455@lll-crg.ARPA>
Date: Tue, 12-Mar-85 02:37:08 EST
Article-I.D.: lll-crg.455
Posted: Tue Mar 12 02:37:08 1985
Date-Received: Thu, 14-Mar-85 04:43:22 EST
References: <320@cubsvax.UUCP> <433@lll-crg.ARPA> <1067@reed.UUCP>
Organization: Lawrence Livermore Labs, CRG group
Lines: 23
Xref: watmath net.bugs:569 net.unix:3922 net.lang.c:4744 net.math:1898

> > A better way around the problem is to use the more
> > sophisticated random number generator random() all of its bits are supposed
> > to be random and its really not that much slower than rand().  A simple
> > #define rand random can fix your code.
> 
>   Our version of 4.2 random() ALWAYS returns an even number the first time it
> is called after being seeded. That effectively breaks small applications
> that call random only once.  (Or those that seed it for every call).
> 
>   	alexis

The context of my bug fix was for applications that use many calls to rand
and don't want the pattern appearing in the low bits.

The question of generating a single number for an application such as fortune
is a different can of worms.  I don't deal with applications like fortune and
such but there is a reasonable way of doing them also.  The trick is to get
two seeds out of the environment somehow.  You can use the time, the number of
active jobs, the phase of the moon {don't have /dev/moon on your system? :-)}
and as much other crap as you can hash together.  Use one seed to seed the
random number generator.  Use the other to call the generator a few times.
Then get your random number from it.  Probably the only way to do better
is with a shot noise generator.  These don't generate lists.