From owner-cvs-all Sun Feb 25 0:40:45 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id DE95F37B401; Sun, 25 Feb 2001 00:40:35 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA30691; Sun, 25 Feb 2001 19:40:26 +1100 Date: Sun, 25 Feb 2001 19:35:41 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kris Kennaway Cc: Matt Dillon , Robert Watson , Nick Sayer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random In-Reply-To: <20010224225935.A769@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 24 Feb 2001, Kris Kennaway wrote: > On Sat, Feb 24, 2001 at 10:40:00PM -0800, Matt Dillon wrote: > > I agree with Bruce that throwing a warning in for simply using > > rand() or rand_r() is not appropriate. The man page says its > > obsolete and that is good enough. We can only protect programmers > > from themselves to a point, after that we are wasting our time. > > This isn't true -- as it stands now, people are writing code which > produces bad behaviour (e.g. the xglobe stars thing), or is insecure, > because they are ignoring the documentation. If we add a link-time > warning it will probably catch more software writers, and the net > result is positive. It also points out instances of possibly bad Probability epsilon. The "mktemp() possibly used unsafely" warning is about a much more important problem; it is very annoying, but not annoying enough for many uses of mktemp() to actually go away even in /usr/src (excuse: many or most of them are in gcc or binutils). > Bruce's objection is on different grounds, and I'll think about how we > can improve rand() without breaking the standards. Actually, on that > matter, I have the suspicion that the rand() implementation (i.e. the > algorithm it uses) is standardized somewhere (one of the C > standards?). Bruce, can you confirm? 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message