Date: Sun, 02 Feb 2003 16:14:54 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mark Murray <mark@grondar.org> Cc: Bakul Shah <bakul@bitblocks.com>, current@FreeBSD.ORG Subject: Re: rand() is broken Message-ID: <3E3DB47E.C29F5D67@mindspring.com> References: <200302022106.h12L6naX051530@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3DB47E.C29F5D67>