From owner-cvs-all Sun Feb 25 1: 0:32 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B4C9E37B4EC; Sun, 25 Feb 2001 01:00:27 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1P90Qc12868; Sun, 25 Feb 2001 01:00:26 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 01:00:26 -0800 (PST) From: Matt Dillon Message-Id: <200102250900.f1P90Qc12868@earth.backplane.com> To: Bruce Evans Cc: Kris Kennaway , Robert Watson , Nick Sayer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :The C standard just gives an example of a portable implementation without :saying that it is a bad example. : :On second thoughts, the standard rand() is somewhat broken as designed. :"unsigned int" seed limits it to UINT_MAX sequences, and there is no :way to ask for irreproducible randomness. : :Bruce Yes, but on the otherhand there are a huge class of applications that don't need irreproducible randomness. For example, games, many classes of math problems, EE and other simulations... quite a few things do just fine with a standard pseudo-random sequence. It's only security and cryptography where rand() really breaks down. These are certainly important application classes, but they are by no means the *only* application class to consider. I see no reason to marginalize 'everything else' with a warning. I'm not that paranoid. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message