[comp.bugs.4bsd] SunOS3.2 rand

ok@quintus (11/27/88)

The SunOS 3.2 on-line manual page for rand(3v) says:
     rand uses a multiplicative congruential random  number  gen-
     erator  with period 2**32 to return successive pseudo-random
     numbers in the range from 0 to (2**15)-1.

In fact it generates 31-bit integers, as the following test program shows:
main()
    {
	extern int rand();
	extern void srand();
	int i;

	srand(21345);
	for (i = 1; i <= 20; i++) printf("%12d\n", rand());
    }
--

This program generates identical results on a Sun-3/60 and a Sequent 386.
The Sequent documentation describes the range correctly.

The SVID specifies 15-bit results.  The BSD/SV incompatibility is known, but
it looked as though SunOS 3.2 had adopted the SV definition.  Nope, you still
need	(rand()&32767) for portability.

guy@auspex.UUCP (Guy Harris) (11/29/88)

>The SVID specifies 15-bit results.  The BSD/SV incompatibility is
>known,

Actually, as I remember it's a 32V/SV incompatibility; another BSD/S5
difference that was originally an AT&T/AT&T difference....

>but it looked as though SunOS 3.2 had adopted the SV definition.

Which wouldn't have been a good idea, for compatibility reasons.  The
real story is that the "rand" in the 4BSD environment and the "rand" in
the S5 environment differ; at least in 4.0, the former is described in
RAND(3C) and the latter is described in RAND(3V).  This may be the case
in 3.x as well; "man" has the annoying habit of choosing the 3V page
rather than the 3C page if you don't give a section, so "man rand" gives
the S5-environment version.

ok@quintus.uucp (Richard A. O'Keefe) (11/29/88)

In article <527@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>This may be the case 
>in 3.x as well; "man" has the annoying habit of choosing the 3V page
>rather than the 3C page if you don't give a section, so "man rand" gives
>the S5-environment version.

AAARGH!  That's IT!  "man 3c rand" gives me the BSD man page.
This would be reasonable behaviour for "man" if I had /usr/5bin early in
my $PATH, but I haven't got it in my $PATH _at_all_.  Ok, let's count
_that_ as the bug.