Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80400
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.54 as permitted sender)
Message-ID: <54B31F65.90203@gmail.com>
Date: Sun, 11 Jan 2015 17:12:05 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, 
 PHP Internals List <internals@lists.php.net>
References: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me>
In-Reply-To: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> * Get rid of rand(), srand() and getrandmax() * Rename mt_rand(),
> mt_srand() and mt_getrandmax() to rand(), srand(), and getrandmax()
> but add mt_* aliases for backwards-compatibility 

This means rand() and mt_rand() would do the same. That however assumes
that OS's libc random-number functions are and will always be inferior.
Is that the case that we believe?

In any case, I would rather disclaim any specifics about implementation
of rand() other than saying it is using best algorithm we have. If we
decide MT one is the best we can support, so be it.

> * Make mt_srand()
> and srand() do nothing and produce a deprecation notice 

I think this is not a good idea. While we can not guarantee the PRNG we
use always provides the same values for the same srand on every system
for every version, it is the case that it provides them in the same
environment, thus enabling the possibility of testing random-driven
algorithms. Disabling it precludes any such testing, except with
user-level workarounds, which will inevitably be more brittle and
error-prone. This all is for no observable gain.

* Use a
> 64-bit random number generation algorithm on 64-bit platforms (or
> invoke the 32-bit generator twice)

This sounds like a good idea, though it may have BC implications. Is
there a use case we know of where it matters?

-- 
Stas Malyshev
smalyshev@gmail.com