cvs commit: ports/astro/xglobe/files patch-random
Kris Kennaway
--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Feb 24, 2001 at 10:55:24PM -0500, Robert Watson wrote:
> Hmm. I thought there was a BUGS section in rand(3), but apparently not --
> I must be thinking of some other operating system. We need to add one,
> and I'm surprised there isn't one already.
How about this also:
Index: stdlib/rand.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /mnt/ncvs/src/lib/libc/stdlib/rand.c,v
retrieving revision 1.2
diff -u -r1.2 rand.c
--- stdlib/rand.c 1999/05/24 23:30:12 1.2
+++ stdlib/rand.c 2001/02/25 04:13:07
@@ -50,6 +50,8 @@
return ((*ctx =3D *ctx * 1103515245 + 12345) % ((u_long)RAND_MAX + 1));
}
=20
+__warn_references(rand_r,
+ "warning: rand_r() does not produce high-quality random numbers and shoul=
d not generally be used");
=20
int
rand_r(unsigned int *ctx)
@@ -61,6 +63,9 @@
=20
=20
static u_long next =3D 1;
+
+__warn_references(rand,
+ "warning: rand() does not produce high-quality random numbers and should =
not generally be used");
=20
int
rand()
Kris
--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6mIjQWry0BWjoQKURAvflAJ4qNngLSD/w2mxpB4ZcO313nZqK6wCfe6NB
tP/M4il8X8dAsA6iWh2+HBo=
=UlhU
-----END PGP SIGNATURE-----
--tThc/1wpZn/ma/RB--
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Rodney W. Grimes
> I must be thinking of some other operating system. We need to add one,
> and I'm surprised there isn't one already.
It's not in the BUGS section, but the man page is pretty explicit
in a few places and:
DESCRIPTION
These interfaces are obsoleted by random(3).
if you go read random(3) you'll find your ``BUGS'':
BUGS
About 2/3 the speed of rand(3).
The historical implementation used to have a very weak seeding; the ran-
dom sequence did not vary much with the seed. The current implementation
employs a better pseudo-random number generator for the initial state
calculation.
> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
> rob...@fledge.watson.org NAI Labs, Safeport Network Services
>
> On Sat, 24 Feb 2001, Nick Sayer wrote:
>
> > nsayer 2001/02/24 19:06:40 PST
> >
> > Added files:
> > astro/xglobe/files patch-random
> > Log:
> > On my system(s), xglobe's stars show up in diagonal bands. I can only
> > conclude that rand() is not very random. This patch makes xglobe use
> > random() instead, and does a randomdev() in main() for good measure.
> >
> > Approved by: kris
> >
> >
>
>
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgr...@gndrsh.dnsmgr.net
Robert Watson
I must be thinking of some other operating system. We need to add one,
and I'm surprised there isn't one already.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
rob...@fledge.watson.org NAI Labs, Safeport Network Services
On Sat, 24 Feb 2001, Nick Sayer wrote:
> nsayer 2001/02/24 19:06:40 PST
>
> Added files:
> astro/xglobe/files patch-random
> Log:
> On my system(s), xglobe's stars show up in diagonal bands. I can only
> conclude that rand() is not very random. This patch makes xglobe use
> random() instead, and does a randomdev() in main() for good measure.
>
> Approved by: kris
>
>
Nick Sayer
Bruce Evans
> How about this also:
>
> Index: stdlib/rand.c
> ===================================================================
> RCS file: /mnt/ncvs/src/lib/libc/stdlib/rand.c,v
> retrieving revision 1.2
> diff -u -r1.2 rand.c
> --- stdlib/rand.c 1999/05/24 23:30:12 1.2
> +++ stdlib/rand.c 2001/02/25 04:13:07
> @@ -50,6 +50,8 @@
> return ((*ctx = *ctx * 1103515245 + 12345) % ((u_long)RAND_MAX + 1));
> }
>
> +__warn_references(rand_r,
> + "warning: rand_r() does not produce high-quality random numbers and should not generally be used");
...
No. rand_r() should be generally used because it is standard. It is the
implementor's fault that it is low-quality (unlike for gets(), which is
broken as designed).
Bruce
Matt Dillon
:> return ((*ctx = *ctx * 1103515245 + 12345) % ((u_long)RAND_MAX + 1));
:> }
:>
:> +__warn_references(rand_r,
:> + "warning: rand_r() does not produce high-quality random numbers and should not generally be used");
:...
:
:No. rand_r() should be generally used because it is standard. It is the
:implementor's fault that it is low-quality (unlike for gets(), which is
:broken as designed).
:
:Bruce
One of the absolutely most annoying things to me is when I use
strftime() with "%y", for a 2-digit year. I really like GCC
telling me about missing arguments for printf/scanf format
strings. The stupid warning about using a perfectly acceptable
'%y' in an strftime() call is inappropriate, though. There
is no way to turn it off without also turning off print/scanf
missing argument warnings.
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.
-Matt
Kris Kennaway
--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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
software which FreeBSD porters and committers can address, again a
positive change. It wastes no-one's time except about 30 seconds of
mine, which I was happy to give :-)
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?
Kris
--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6mK1XWry0BWjoQKURAkDGAJ9M1LHlvsQz4fiijc0JIW6u/sPb8ACg8RBq
aOzTUR/wb3J9nDdjQywJJOw=
=TvFa
-----END PGP SIGNATURE-----
--tKW2IUtsqtDRztdT--
Matt Dillon
: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
:software which FreeBSD porters and committers can address, again a
:positive change. It wastes no-one's time except about 30 seconds of
:mine, which I was happy to give :-)
All that adding a compile-time warning will do is annoy anyone trying
to use the interface legitimately. If you have a problem with a
particular programmer's use of the interface, you should email that
programmer. We are not responsible for programmers who ignore
documentation. While it is nice to have some warnings in there,
there is a limit to what we should be doing to save the programmer
from himself. Many of these people aren't even using FreeBSD, so
I really doubt that adding #warnings to our compilation environment
will actually do what you think it will do, especially in regards
to ports.
People have gone overboard before... the strftime() warning, for
example, is extremely annoying to me because I am using strftime()
exactly the way it is documented to be used. Some overzealous bozo
decided the best way to warn everyone about Y2K was to cause the
compiler to spew warnings out from 2-digit years formatted with
strftime(). Bah. What you are proposing here is something of the
same ilk.
-Matt
J Wunsch
> How about this also:
> static u_long next = 1;
> +
> +__warn_references(rand,
> + "warning: rand() does not produce high-quality random numbers and should not generally be used");
Objected. rand() is the ANSI/ISO interface, random() is non-standard
und thus unportable. Standard and portable programs should not cause
warnings.
The IMHO better way would be to make rand() use random()'s algorithm,
while retaining the standard-mandated calling interface. Ship the
existing rand()/srand() functions either as orand()/osrand() or
perhaps in libcompat for those who insist that they need the old
algorithm for 20-year old regression test scripts to behave
predictably the same way they did all the previous 20 years.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Bruce Evans
> 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
Erik Trulsson
>
> 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?
>
> Kris
(I am not Bruce, but...)
No, the algorithm of rand() is not standardized in the C standard.
OTOH, there is an example of a portable implementation of rand() in the
C standard and FreeBSD uses the same algorithm (as does many other
implementations of rand()). This is probably what you were thinking of.
As long as rand() and srand() behaves as describe in the man-page for
rand(3) they confirm to the C standard. (Provided that RAND_MAX is at
least 32767.)
--
<Insert your favourite quote here.>
Erik Trulsson
ertr...@student.uu.se
Matt Dillon
: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
Kris Kennaway
--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sun, Feb 25, 2001 at 01:00:26AM -0800, Matt Dillon wrote:
> :
> :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
>=20
> 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, please read the subject line of the thread you're replying to,
and the commit which started it. rand() just isn't very good as it
stands, from other standpoints that security. Please also read my
reply to -arch before responding further.
Kris
--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6mM7mWry0BWjoQKURApk3AJ9wrCNryThBxtwMCrrc/IP4ZB0lNQCcDD32
4euBhLkO4A65zl+n9hiCWUM=
=9sef
-----END PGP SIGNATURE-----
--wRRV7LY7NUeQGEoC--
Matt Dillon
:Matt, please read the subject line of the thread you're replying to,
:and the commit which started it. rand() just isn't very good as it
:stands, from other standpoints that security. Please also read my
:reply to -arch before responding further.
:
:Kris
I went back and read it. It hasn't changed anything. The manual
page for rand() is very specific on the API. If you don't like
the sequence returned you could simply fix rand() in libc to use
srandom() without breaking the spec. But putting a #warning in
is not appropriate. There is nothing fundamentally wrong with
the API - in fact, it's almost exactly the same API that srandom()
uses except srandom() provides for a larger range of options in
regards to seeding. Adding a #warning is adding a hack rather then
adding a fix. You may not like the fact that rand() can never be
cryptographically secure, but that doesn't illegitimize rand(). As
I said, there is a huge class of problems for which a fixed pseudo
random sequence is perfectly acceptable.
-Matt
Kris Kennaway
--M9NhX3UHpAaciwkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 25, 2001 at 01:33:07AM -0800, Matt Dillon wrote:
> :
> :Matt, please read the subject line of the thread you're replying to,
> :and the commit which started it. rand() just isn't very good as it
> :stands, from other standpoints that security. Please also read my
> :reply to -arch before responding further.
> :
> :Kris
>=20
> I went back and read it. It hasn't changed anything. The manual
> page for rand() is very specific on the API. If you don't like
> the sequence returned you could simply fix rand() in libc to use
> srandom() without breaking the spec. But putting a #warning in
Gah, didn't I also tell you to go and read my reply on -arch? *sigh*
> I said, there is a huge class of problems for which a fixed pseudo
> random sequence is perfectly acceptable.
And you're still missing the point that some non-cryptographic
applications of rand() as it stands are invalid, because of the reason
noted in the commit message. However, I'll ask you a third time to
read my followup on -arch.
Kris
--M9NhX3UHpAaciwkO
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6mOZCWry0BWjoQKURAjJqAJ9xU87YxQBrXAqOyjicmDHduQACRwCfcLZN
O38eoTbXIirImhgy8HIzSu8=
=Epvh
-----END PGP SIGNATURE-----
--M9NhX3UHpAaciwkO--
Jacques A. Vidrine
> It's only security and cryptography where rand() really breaks down.
This is simply not true in my experience. I fixed two ports in the
recent past that were using rand/srand, because:
Case 1: A game's sound-effects that were essentially white-noise
(e.g. explosions) sounded silly. Using random/srandom
made it sound much better.
Case 2: XMMS used rand/srand to shuffle the playlist. I have a
4000+ item playlist, and the shuffle was noticeably not
very random. Changing XMMS to use random/srandom fixed
this.
My conclusion is that either:
Our implementation of `rand' loses.
OR
`rand' has inherent limitations that make it unsuitable for
most applications.
Cheers,
--
Jacques Vidrine / n...@nectar.com / jvid...@verio.net / nec...@FreeBSD.org
Andrey A. Chernov
> My conclusion is that either:
>
> Our implementation of `rand' loses.
We can easily improve much our rand() random distribution staying inside
the same API by using just different calculation formula, as we already do
with random(). I plan to do it long time ago, but lost interest. I can dig
out this formula, if someone is interested.
--
Andrey A. Chernov
http://ache.pp.ru/
Andrey A. Chernov
> On Sun, Feb 25, 2001 at 09:24:16 -0600, Jacques A. Vidrine wrote:
> > My conclusion is that either:
> >
> > Our implementation of `rand' loses.
>
> We can easily improve much our rand() random distribution staying inside
> the same API by using just different calculation formula, as we already do
> with random(). I plan to do it long time ago, but lost interest. I can dig
> out this formula, if someone is interested.
We already use this formula (in different context), see
good_rand() function in stdlib/random.c