On Wed, Mar 18, 2015 at 09:33:53AM -0600, Theo de Raadt wrote:
> [I mistakenly sent the wrong diff, sorry, here is the right diff]
> 
> This is a further proposal for unification of the random number
> generator functions in our tree.  It is based upon my previous work,
> but takes things a bit further.
> 
> I am sending this now, but it is too early to commit.  I think we need
> two weeks of testing and review of the impact this has on OpenBSD and
> portability to other systems. I am hoping this can go into the tree at
> the start of the new month, just before the ports hackathon because
> providing them with an unexpected libc library crank is always
> entertaining.
> 
> On to the diff:
> 
> Since rand() is now a wrapper around arc4random(), it gains the new
> strong randomness semantics, and we can call it directly.
> 
> I recognize there will be some who are upset about the uint32_t -> int
> change for the return value, but we have accepted this incorrect
> return type on snprintf() and other such "standards derived errors"
> for so long, maybe this concern is overblown?
> 
> In any case ANSI X3.159-1989 prohibits us from changing the return
> type of rand().
> 
> I have also added matching rand_uniform() and rand_buf() functions.
> Bob Beck has pointed out this allows for later audit converting a few
> "rand() % moduli" cases into rand_uniform().
> 
> At 1900 lines, the diff is a bit long, but I am uncertain about
> splitting it up.  This only changes userland.  The kernel never had
> the ANSI C versions, but maybe we can unify in that direction in the
> future.
> 
> Naturally, the diff starts in the games directory:

I understood the rationale for changing OpenBSD's rand*(3) functions to be
non-deterministic, but this is not a safe assumption for software outside
the OpenBSD tree.. I can't see the motivation for this, other operating
systems are already adopting the arc4random interfaces, albeit they
slow to sync with OpenBSD..

April fools?

-Bryan.

Reply via email to