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