On Wed, Dec 07, 2005 at 10:22:37PM +0100, Lorenz Minder wrote:

> 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().

Certainly; however, let's not forget for a moment that those
epitomize the standardization of existing practice.  In this
case it's an interface introduced in 4.2BSD (in 1983); I'll
spare you the application portability considerations concluding in
the introduction of an altogether new interface, and those of
performance set aside, too.  (In System V, similar considerations
resulted drand48().)  random() et al. have since been widely
adopted by other implementations in both general-purpose and
embedded markets - and even where XSI isn't fully supported;
hence I find this argument rather unconvincing.

Also, the C standard offers (suggests) its own rand() implementation,
which likely serves as a warning.


> > 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.

Bzzzt.  Conformance is not a consideration at this point; asymmetry
being a hallmark of bad interface design is.  (Do you happen to
consider rand_r() a second-class citizen since it's not in the
base standard but part of TSF?)


> > 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().

To clarify, conformance was the show-stopper reason why the change,
as originally submitted, should not go in, independently of my
concerns about computational cost and interface design.


> >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.)

Sure, I concede it's an instance of interface bloat.  Heck, if it
wasn't for the C standard rand() even might have been binned into
libcompat, considering the warning signs that have been posted.
Sadly, this is not an ideal word.


> >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 did let my opinion float in an informal developer setting; of those
who decided to voice theirs, all concurred.


Best regards,
- Klaus