The following reply was made to PR lib/32258; it has been noted by GNATS.

From: Lorenz Minder <lminder@gmx.net>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org, kleink@netbsd.org
Subject: Re: lib/32258 (rand() creates bad random numbers.)
Date: Wed, 7 Dec 2005 22:22:37 +0100

 Hi,
 
 Thanks for your comments!
 
 I hope I can still add mine, even though you already closed the report.
 
 kleink@netbsd.org wrote:
 > First, random() may not be in both ISO C and POSIX, but it actually is
 > in POSIX, which makes the availability picture not as gloomy as you're
 > drawing it.
 
 I just checked. It is in POSIX, but part of XSI, which is not mandatory.
 IOW, the point is that a POSIX compliant does not necessarily ship
 random().
 
 > Second, the proposed patch is missing rand_r().  The question whether
 > this was omitted intenionally or not set aside, neither the resulting
 > asymmetry of rand() and rand_r() nor the non-availability of the
 > caller-supplied seed to rand_r() through a wrapping around random()
 > are desirable outcomes.
 
 Yes, there is an asymmetry.
 
 It's an asymmettry *in the interface*: The interface makes it impossible
 to write a good conforming rand_r(), while a good conforming
 implementation of rand() is possible.
 
 Should implementations try to hide the assymmetry in the interface? I
 fail to see why.
 
 > Third, turning this into wrappers around random() using the same
 > state would result in an implementation no longer conforming to the
 > standard,
 
 That is a valid concern, which I had already pointed out in my original
 mail.
 
 I had also explained why I think it is likely. Anyway, I would be happy
 to provide a version which fixes this, if this is the main reason for
 not providing a better rand().
 
 >and applications must be able to rely on the property of
 > sequence repeatability despite intermediate modification of the
 > random() state.  On the other hand, I agree with the observation
 > that adding extra state for rand() would be bloat.
 
 Ok, so that gives?
 
 (I hope we agree, btw, that providing a bad RNG along side with a good
 one is also a---if minor---form of bloat.)
 
 > Also, I'd like to note that there are applications where the cheapness
 > of a PRNG comes before its quality; that's why there are several to
 > choose from, and rand() has forever been known to address the
 > aforementioned needs.
 
 Yes, I seem to recall having heard that argument in other contexts as
 well. I've never encountered a use, which of course doesn't mean there
 isn't any, but the intersection of { need many random numbers } and {
 they needn't be good } seems pretty small nevertheless.
 
 >In summary, I think this change should not be
 > applied.
 
 I would like to know if it is just you, or if there is strong consensus
 within the NetBSD community that a similar change should not be applied.
 
 I for one fail to see why a good RNG should be worse than a bad one.
 
 Best,
 --Lorenz