Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54B32145.80501@gmail.com>
Date: Mon, 12 Jan 2015 01:31:50 +0000
Cc: Jordi Boggiano <j.boggiano@seld.be>,
 Yasuo Ohgaki <yohgaki@ohgaki.net>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B3E640CE-0361-4132-A849-20AFFC9D7AA8@ajf.me>
References: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me> <54B30DB9.3000003@seld.be> <76B8D342-43E7-42E6-AD82-FCF7C5CA8658@ajf.me> <54B31D77.9010100@gmail.com> <976B7B2E-7BC9-4514-ABF3-C0DA3ED98897@ajf.me> <54B32145.80501@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 12 Jan 2015, at 01:20, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
>> The manual explicitly guarantees that code should not rely on the
>> random number generator being predictable.
>=20
> Where exactly does it say that? The only note I've found is this:
> http://php.net/manual/en/function.mt-srand.php
>=20
> 5.2.1	The Mersenne Twister implementation in PHP now uses a new =
seeding
> algorithm by Richard Wagner. Identical seeds no longer produce the =
same
> sequence of values they did in previous versions. This behavior is not
> expected to change again, but it is considered unsafe to rely upon it
> nonetheless.
>=20
> Which just says we could change PRNG behavior between versions, and
> nothing about PRNG not being predictable.

It says it=92s unsafe to rely upon the behaviour of seeding.

Also, FWIW, anyone who used the Suhosin patch couldn=92t use srand() =
because it disabled it.

>> If people want their existing code to continue to work, we could of
>> course allow this new API to support the C stdlib rand() as an
>> algorithm for BC reasons. But such code was never supposed to work in
>> this first place.
>=20
> If it works, breaking it should have a very good reason. I don't see =
any
> reason to break srand().

Because if we don=92t break it, people will continue to rely on it, and =
this binds our hands for future versions.=20

Also, those people will have their code break anyway if they upgrade =
their OS and it changes its random number generator.

Just because people do rely on it doesn=92t mean they should or that we =
should continue to allow them to.

--
Andrea Faulds
http://ajf.me/