Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] random() function produces wrong range

From: Thomas Swan <tswan(at)olemiss(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Malcolm Beattie <mbeattie(at)sable(dot)ox(dot)ac(dot)uk>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [HACKERS] random() function produces wrong range
Date: 2000-08-03 03:23:07
Message-ID: 4.3.2.7.2.20000802222151.02ca3a90@sunset.backbone.olemiss.edu (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
> >> none of the man pages I've looked at so far mention it).  But all the
> >> machines say that the output of random() is 31 bits, so INT_MAX should
> >> work.
>
> > SuSv2 says explicitly 2^31-1 so you should use that, otherwise you'll
> > be non-portable to platforms with 64-bit ints, for example.
>
>Maybe.  You don't think that a 64-bit-int platform would choose to
>supply a random() function with a range of 2^63-1?  The HPUX and SunOS
>man pages clearly specify that random()'s result is "long", so I think
>a case could also be made for LONG_MAX.
>
>I suspect we have a good chance at getting burned no matter what we use
>:-(.  But RAND_MAX is definitely the wrong thing.

Is it possible to test (during configure phase) and then go from there... 
or does it need to be the same for all platforms?

-
- Thomas Swan
- Graduate Student  - Computer Science
- The University of Mississippi
-
- "People can be categorized into two fundamental
- groups, those that divide people into two groups
- and those that don't."

In response to

Responses

pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-08-03 04:40:23
Subject: Raw constraint & pg_relcheck.rcsrc
Previous:From: Tom LaneDate: 2000-08-03 01:36:38
Subject: Re: comparing rows

pgsql-general by date

Next:From: Guy FraserDate: 2000-08-03 03:44:49
Subject: Re: VS: Backup/dump of huge tables and performance
Previous:From: Christopher SmithDate: 2000-08-02 23:26:01
Subject: Re: Slash on PostgreSQL mailing list

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group