Matt Chapman wrote:
> primFun(primGetRandomSeed) { /* generate a random seed */
> IOReturn(bigInt(clock()));
> }
>
> The clock() function returns the processor time used by the current
> process, to the nearest clock tick. Thus the returned seed will
> recur quite frequently between successive invocations of Hugs.
>
> Is there any good reason why clock() is used here? I can only speculate
> that a time(NULL) or gettimeofday(...) call was intended instead.
>
> The first method, time(NULL), still seems to exhibit some non-random
> behaviour, as the returned times will be close together.
>
> [...]
>
> Certainly either of these methods yields better random numbers than
> the current clock() implementation, and both are at least as portable
> as clock().
I believe I'm responsible for this particular hack.
I think I deliberately chose clock instead of time or gettimeofday
because of portability concerns - even though the other two yield much
better results. Portability is a tricky beast - you have to look at
standards and then check whether they're implemented on a decent range
of systems. The man pages on my machine say that clock is in ISO C
but make no such claims for time (comes from Version 6 AT&T Unix) or
gettimeofday (comes from 4.2BSD) so I'm guessing that I decided that
clock was more portable.
If anyone did feel like fixing this, something along the following lines
would be fairly portable (need to add a gettimeofday test to autoconf).
#ifdef HAVE_TIME_H
#include <time.h>
#endif
primFun(primGetRandomSeed) { /* generate a random seed */
#if BIGNUMS && defined HAVE_GETTIMEOFDAY
struct timeval tv;
gettimeofday(&tv, NULL);
IOReturn(bigInt((tv.tv_usec << 12) + tv.tv_sec));
#elif BIGNUMS && defined HAVE_TIME_H
#warning "Using bad implementation of getRandomSeed"
IOReturn(bigInt(clock()));
#else
#warning "getRandomSeed not available on this architecture"
ERRMSG(0) "getRandomSeed is not implemented on this architecture"
EEND;
#endif
}
--
Alastair Reid [EMAIL PROTECTED] http://www2.cs.utah.edu/~reid/
