🚀 go-pugleaf

In <1990Jul24.133823.6608@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes:

>In article <483@keele.keele.ac.uk> writes:

>>My problem is that C has the two routines srand and rand. The latter
>>returning an integer in the range 0-32767 (0 -> (2^15)-1). If I am

>C has no such thing.  UNIX has such things.  Rand and srand are outdated
>relics of the PDP-11 era, and have been replaced on almost all (?) UNIX
>systems by random and srandom, which return 32-bit values.  If your UNIX
>system supports these, use them and avoid the problem!

I don't know if all the C people have stopped reading this newsgroup, or
if they are asleep, or just don't care, but I've waited about a week and
haven't seen anyone refute this.  What you say about rand() and srand() is
just not true.  They certainly are a part of C.  That is they are a part of
ANSI C and are a part of many (most? all?) pre-ANSI C libraries.  And they
haven't been replaced on any UNIX systems that I know of; in fact, the 3
UNIX systems that I just checked (5.2, 5.3, and 5.4) all have rand()/srand()
but none of them have random() (perhaps random() is BSD).

>In any case, even on 32-bit UNIX machines when called from C, rand returns
>random values only in the 16 high-order bits, so when using these functions
>even from C it is necessary to do a 16-bit shift to the "right".  Without
>this, the sequence of numbers returned alternates strictly between even
>and odd (at least it did on a VAX running ULTRIX) -- scarcely pseudorandom
>behavior!

It's true that most versions of rand() return values in the range 0-32767,
even on 32-bit machines, but they are in the low-order bits.  If VAX/ULTRIX
returns them in the high-order bits, then either it's broken or you've
messed something up (or are confused about left/right vs. high/low).

-- Rick Schubert (rns@se-sd.sandiego.NCR.COM)