From owner-freebsd-current Sun Feb 16 21:41: 3 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF4E137B401; Sun, 16 Feb 2003 21:41:01 -0800 (PST) Received: from dilbert.robbins.dropbear.id.au (069.c.009.mel.iprimus.net.au [210.50.114.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3C4643F3F; Sun, 16 Feb 2003 21:40:58 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au (zoy7eyipt6vxmkad@localhost [127.0.0.1]) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6) with ESMTP id h1H5eomq029127; Mon, 17 Feb 2003 16:40:50 +1100 (EST) (envelope-from tim@dilbert.robbins.dropbear.id.au) Received: (from tim@localhost) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6/Submit) id h1H5em29029126; Mon, 17 Feb 2003 16:40:49 +1100 (EST) (envelope-from tim) Date: Mon, 17 Feb 2003 16:40:48 +1100 From: Tim Robbins To: Kris Kennaway Cc: "Andrey A. Chernov" , current@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdlib rand.c Message-ID: <20030217164048.A28273@dilbert.robbins.dropbear.id.au> References: <200302170352.h1H3qawJ062671@repoman.freebsd.org> <20030217045729.GA68471@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030217045729.GA68471@rot13.obsecurity.org>; from kris@obsecurity.org on Sun, Feb 16, 2003 at 08:57:29PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 16, 2003 at 08:57:29PM -0800, Kris Kennaway wrote: > On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: > > > So, monotonically increased seed->first value correlation problem remains... > > I think we should commit this patch (to -current) and fix all the > problems that pop up. For example, it's used in awk (which started > this set of changes), and in some of the XFree86 libraries. > > Kris > > Index: stdlib/rand.c > =================================================================== > RCS file: /mnt2/ncvs/src/lib/libc/stdlib/rand.c,v > retrieving revision 1.14 > diff -u -r1.14 rand.c > --- stdlib/rand.c 5 Feb 2003 21:25:50 -0000 1.14 > +++ stdlib/rand.c 8 Feb 2003 06:07:55 -0000 > @@ -86,6 +86,8 @@ > #endif /* !USE_WEAK_SEEDING */ > } > > +__warn_references(rand_r, > + "warning: rand_r() does not produce high-quality random numbers and should not generally be used"); > > int > rand_r(unsigned int *ctx) > @@ -99,6 +101,9 @@ > > > static u_long next = 892053144; /* after srand(1), NSHUFF counted */ > + > +__warn_references(rand, > + "warning: rand() does not produce high-quality random numbers and should not generally be used"); > > int > rand() I disagree. It's safe to use rand() in games and in certain kinds of simulations when you don't care that the distribution isn't quite uniform, or when you prefer speed over quality. I don't think rand() needs a warning message like gets() &c. because it's not as dangerous. What I suggest instead is to remove the pathetic "insults" in rand(3) ("bad" random number generator, obsoleted) and add a BUGS section which describes the problem. I'd much prefer that rand() generated higher quality numbers, though. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message