Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54B31F65.90203@gmail.com>
Date: Mon, 12 Jan 2015 01:25:30 +0000
Cc: PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D58CFA23-F364-4707-92AC-849A2F23C08E@ajf.me>
References: <E472413E-7615-49F9-BE6C-AAA0088C3F53@ajf.me> <54B31F65.90203@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] rand(), mt_rand() and limits
From: ajf@ajf.me (Andrea Faulds)

Hey,

> On 12 Jan 2015, at 01:12, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
>> * 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=20
>=20
> 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?

Quite possibly not, but we know that some OSes do have inferior rand() =
implementations and using our own ensures cross-platform uniformity. =
Using our own implementation shields users from sucky stdlibs.

> 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.

Yeah, I agree there.

>> * Make mt_srand()
>> and srand() do nothing and produce a deprecation notice=20
>=20
> 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.

Such algorithms really shouldn=E2=80=99t be using rand() or mt_rand(), =
they aren=E2=80=99t fit for purpose for reasons I=E2=80=99ve previously =
elaborated.

Code which needs to do what you=E2=80=99re describing should use an API =
made specifically for that purpose. There are userland packages for =
this. We could also add a standard library class like I suggested =
earlier. I don=E2=80=99t really see why a userland DRBG would =
necessarily be =E2=80=9Cbrittle and error-prone=E2=80=9D. Not unless =
they=E2=80=99re using some completely unmaintained library.

> * Use a
>> 64-bit random number generation algorithm on 64-bit platforms (or
>> invoke the 32-bit generator twice)
>=20
> This sounds like a good idea, though it may have BC implications. Is
> there a use case we know of where it matters?

I can=E2=80=99t immediately think of one, but I can=E2=80=99t imagine =
there wouldn=E2=80=99t be a need for values larger than 2^32.

By the way, I=E2=80=99m not sure what I=E2=80=99ll do for rand() for the =
bigint RFC/patch. I might just use the bigint library=E2=80=99s random =
function when the range is wider than that a native integer has, but I =
can=E2=80=99t do that if we allow seeding (because it breaks predictable =
sequence generation). Alternatively, I could just not make it work with =
bigints, since producing incredibly large numbers can of course be done =
manually with bitwise shifts and multiple mt_rand() invocations.

--
Andrea Faulds
http://ajf.me/