src-test2/lib/libc/stdlib/rand.c, branch release/5.4.0_cvs

This commit was manufactured by cvs2svn to create tag

2005-05-07T17:51:10Z

'RELENG_5_4_0_RELEASE'. This commit was manufactured to restore the state of the 5.4-RELEASE image.

Back out "drop first N values" method of removing monotonically increased

2003-02-17T03:52:35Z

seed->first value correlation. It breaks rand_r()... Other possible methods like shuffling inside aray will breaks rand_r() too, because it assumes only one word state, i.e. nothing extra can be added after seed assignment in srand(). BTW, for old formulae seed->first value correlation is not so monotonically increased as with other Linear Congruential Generators of this type only becase arithmetic overflow happens. But overflow affects distribution and lower bits very badly, as many articles says, such type of overflow not improves PRNG. So, monotonically increased seed->first value correlation problem remains...

Since we drop NSHUFF values now, set default seed to what it becomes

2003-02-05T21:25:50Z

after srand(1)

For rand(3) and random(3) TYPE_0 drop NSHUFF values right after srand{om}()

2003-02-04T11:24:08Z

to remove part of seed -> 1st value correlation. Correlation still remains because of algorithm limits. Note that old algorithm have even stronger correlation, especially in the lower bits area, but not eye-visible, as current one.

Park & Miller PRNG can be safely initialized with any value but 0 and stuck

2003-02-03T10:22:12Z

at 0 as designed. Its BSD adaptation tries to fight it by mapping 0 to 2147483647 after calculation, but this method not works since 2147483647 seed returns to 0 again on the next interation. Instead of after calculation mapping, map 0 to another value _before_ calculation, so it never stucks.

For some combinations of variable sizes and RAND_MAX value rand_r()

2003-02-02T14:27:51Z

may store less amount bits for seed, than available. Fix it.

Add missing #include "namespace.h".

2003-01-03T23:38:21Z

Fix the style of the SCM ID's.

2002-03-22T21:53:29Z

I believe have made all of libc .c's as consistent as possible.

Add a long-overdue nail to the deprecated /dev/urandom interface

2001-10-30T21:26:50Z

by asking some things that need unpredictable numbers to read /dev/random instead.

urandom(4) -> random(4) in comments.

2001-06-07T02:32:18Z

PR: 27858 Submitted by: Yoshihiro Koya Reviewed by: md5(1) Approved by: markm