From owner-freebsd-current Sun Feb 2 16:16:32 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 B457F37B401 for ; Sun, 2 Feb 2003 16:16:30 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B4F143F3F for ; Sun, 2 Feb 2003 16:16:25 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0402.cvx21-bradley.dialup.earthlink.net ([209.179.193.147] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18fUHY-0002zA-00; Sun, 02 Feb 2003 16:16:18 -0800 Message-ID: <3E3DB47E.C29F5D67@mindspring.com> Date: Sun, 02 Feb 2003 16:14:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Bakul Shah , current@FreeBSD.ORG Subject: Re: rand() is broken References: <200302022106.h12L6naX051530@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a436a0dc4695246dac92d96d7c5b8d2764a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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 Mark Murray wrote: > Bakul Shah writes: > > random(3) also provides an initstate() call which presumably > > allows you to change the amount of randomnes. So here is > > another suggestion: why not fold your algorithm change in > > that function? For example, > > > > initstate(seed, "RC4", 3); > > > > changes the algorithm to RC4. Yes, this is a change in the > > interface but one I am sure most people can live with. > > No. Evil interface change. #ifdef hell while programs try to > figure out OS differences. Definitely agree. Interface changes are bad. > If an os provides a function, that function should be as good > as possible while not breaking standards. There are standards, and there are defacto standards. I really like the idea of a crypto_random() (and a crypto_rand()) that the weenies who want something different from the historical BSD implementations can use. > We have lousy functions like gets(3), that we have to keep > because the standards say we do and programmers keep on writing > code that uses them. Complaining about the ability to perform buffer overflows in code that is not SUID/SGID, thereby harming only yourself, is dumb. But... if you are going to keep gets/sprintf/strcpy/etc., just because you think you have to, even though you think they are dumb, then it's probably right to keep historical algorithms intact (technically, buffer overflows in gets() are only possible because the historical algorithm is being kept intact). > rand() and random() have a docimented interface, and empirical > programmer expectations about their outputs simply result in > bad code. Same for use of gets/sprintf/strcpy/etc. for Tuesday's definition of "bad code". I'd argue that providing threads results in bad code, too, but that doesn't mean that they're ging away any time soon. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message