Re: lib/38883: Replace the algorithm used by random (3) by the Mersenne Twister (mertwist.c)

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Alan Barrett <apb%cequrux.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: lib/38883: Replace the algorithm used by random (3) by the
        Mersenne Twister (mertwist.c)
Date: Sun, 31 Aug 2008 19:00:51 +0000

 On Mon, Aug 25, 2008 at 12:22:56PM +0200, Alan Barrett wrote:
  > On Mon, 25 Aug 2008, David Holland wrote:
  > >  > Thus, why not implement it as the standard algorithm for random (3)
  > >  > group of calls?
  > >  
  > >  We can't (or at least shouldn't) do this because it would break the
  > >  initstate() and setstate() interface to random(3).
  > 
  > Do people really expect the kind of repatability offered by the
  > initstate/getstate interface to persist across operating system
  > upgrades?  In other words, do we guarantee that values returned by
  > initstate befoer an upgrade may be passed to setstate after an upgrade?
 
 I'm not sure. I once came very close to writing code that did, but
 that was a long time ago and used getstate() as well as setstate(),
 which we don't seem to support.
 
  > Even if we do need to retain this level of compatibility, there seem
  > to be enough unused values in the first (int) of the state array that
  > we could encode which algorithm is used.  Old algorithms would still
  > have to work as if the old value of MAX_TYPES were retained, but it's
  > nevertheless possible to add new algotithms.
 
 That sounds promising though, provided that it's actually worth
 deploying another algorithm.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost