Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94212
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.87 cause and error)
Reply-To: internals@lists.php.net
References: <CAPwsocFZQdU2bt0OETeJMQYBXVUkK8ygB5jTb4ML3df4GZWdVA@mail.gmail.com>
 <e28227a3-d5b1-b971-3362-c6d31768aa44@fleshgrinder.com>
 <cf009374-d159-886c-3a25-643ebb7f91e5@gmail.com>
 <f5807c28-6f0e-d7a7-b460-335cb0354d07@seld.be>
 <2f92fa26-5f50-0e68-c1fc-de79f17c201e@fleshgrinder.com>
 <8b48f847-bbba-03f8-4b2e-9cd0841b484e@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net,
 Tom Worster <fsb@thefsb.org>
Message-ID: <65ea0142-c2d6-f4ed-e98e-b7c7fbc51c58@fleshgrinder.com>
Date: Wed, 22 Jun 2016 19:46:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <8b48f847-bbba-03f8-4b2e-9cd0841b484e@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="moq0KUGrMOL5kiipj4Dg3vpEmsw4ULWkN"
Subject: Re: [PHP-DEV] [RFC] RNG fixes
From: php@fleshgrinder.com (Fleshgrinder)

--moq0KUGrMOL5kiipj4Dg3vpEmsw4ULWkN
Content-Type: multipart/mixed; boundary="tsmt3SOJ6x75K9Oq652EXXElmXuaNDSxu"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net,
 Tom Worster <fsb@thefsb.org>
Message-ID: <65ea0142-c2d6-f4ed-e98e-b7c7fbc51c58@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC] RNG fixes
References: <CAPwsocFZQdU2bt0OETeJMQYBXVUkK8ygB5jTb4ML3df4GZWdVA@mail.gmail.com>
 <e28227a3-d5b1-b971-3362-c6d31768aa44@fleshgrinder.com>
 <cf009374-d159-886c-3a25-643ebb7f91e5@gmail.com>
 <f5807c28-6f0e-d7a7-b460-335cb0354d07@seld.be>
 <2f92fa26-5f50-0e68-c1fc-de79f17c201e@fleshgrinder.com>
 <8b48f847-bbba-03f8-4b2e-9cd0841b484e@gmail.com>
In-Reply-To: <8b48f847-bbba-03f8-4b2e-9cd0841b484e@gmail.com>

--tsmt3SOJ6x75K9Oq652EXXElmXuaNDSxu
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/21/2016 11:40 PM, Rowan Collins wrote:
> Hi,
>=20
> I already wrote this message once, but it seems to have evaporated into=

> the ether. So apologies if it reappears and this is revealed as a poor
> duplicate of it!
>=20
> I think the push to remove "cruft" would make more sense if the
> replacements were less obviously "cruft" in their own right. If I have
> to polyfill pcg_rand() on old servers and mt_rand() on new ones, I'd be=

> tempted to just implement wtfbbq_rand() and have done with it, because
> the names, and even the algorithms they represent, are pretty
> meaningless to me.
>=20
> As with libsodium, I think we should avoid replacing one set of
> overly-specific implementations with another, and saying "this time
> we've got it right". Instead, we should look at what people actually
> want the functions *for*, and hide the implementation as much as possib=
le.
>=20
> For instance, for reproducible (seedable) random sequences, how about a=

> function random_int_sequence($seed, $min, $max) which returns a
> generator, so you could write "$user_seq =3D
> random_int_sequence($user_seed, 0, 10); $user_pick =3D $user_seq();" Or=

> maybe it could return a closure, or an object - either way, something t=
o
> replace the global state of (mt_)srand.
>=20
> Perhaps a random_int_fast() function with big warnings that it's not to=

> be trusted for crypto, but performs really well if all you're doing is
> picking which image banner to show on your home page.
>=20
> Use whatever RNG you want under the hood, make a declaration of whether=

> or not it's stable cross-platform and cross-version, and give users an
> actual reason to change their code. Then consider other use cases: a
> better uniqid(), shuffling, maybe built-in UUID support...
>=20
> Then, IF the new APIs become popular, we can come back to talking about=

> removing rand() and mt_rand(), because we'll have replaced them with
> something substantially better, not just another variant on the same th=
ing.
>=20
> Regards,
>=20

Yes, yes, yes! :)

I would still like to deprecate rand() but probably leave it to Nikic
because people actually listen to him. ;)

@Tom Worster: I will not answer to any other message in this thread
today but I think we are essentially on the same page regarding PCG and
its suitability for PHP, it just needs time to mature. I think we also
agree regarding the MT situation.

However, I think that it makes sense to tackle the problem that people
use mt_rand() incorrectly and Rowan's proposal here matches the last
proposal I made: it's just even better and he is as always much better
in summing things up. :)

Maybe we could do some name brain storming?

1. random_int_sequence()
2. random_int_fast()
3. random_int_seedable()
4. random_pseudo_int()
5. pseudorandom_int()
6. random_deterministic_int()
7. deterministic_random_int()
8. ????

[1] Somehow unclear what sequence means here if you just want to
randomly pick an entry from an array.

[2] This might still suggest to people that they can use it for crypto,
just faster. I really like it but I don't think its perfect.

[3] Sounds nice to me.

[4] What is a pseudo int?

[5] Would create a new prefix and probably not show up in some code
completions together with the other random functions. :( Other than that
it would describe it best.

[6] Long but to the point.

[7] Again too long and it creates a shitty new prefix.

The signature is clear in my opinion and exactly as Rowan had it:

prng(int $seed, ?int $min =3D 0, ?int $max =3D PHP_INT_MAX): int;

--=20
Richard "Fleshgrinder" Fussenegger


--tsmt3SOJ6x75K9Oq652EXXElmXuaNDSxu--

--moq0KUGrMOL5kiipj4Dg3vpEmsw4ULWkN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXas8XAAoJEOKkKcqFPVVrfbsP/3CzcPYSOT/eB/kYg50I74F4
YRfxLd3leiTJaUHbMmoaj/wzZdVUmDq+HuLAwh9UxWx0Kw+cjMuSNq0xLsh+HltW
OxqqskaaDUWn+9/WSi/8F1caIG2lRYRc3zXBWEBG+hVF1PQQ1kxbGOrdjepmzkfP
foLrQED4wLJhmVLx0Vp85/aIbMLtB3vOLNJ+hKhiNWW3w7ePbCtd8YbupQ6nvgUd
T5Vdhd+Oj9s9hmlhkTXlGmKzqGMEMot9AkcYIy/Si6gZIAmNv0ejwaYTK7NNvgcD
vzNDO1uIxDlTVUXlGBOorc/7cudKYRKP0pmpDq/qp0ZO23j47kAylEAoX/Yii4u9
On3CdLJ8CDPD4bLIC1UxBsfNIzfNnoHjcWMzhIPxqOFnMjy/K2rchV5fSzYLr2r+
2y5Jvlh7rPiE1a3fQXJ3XWAfQdOeTo21CvfLtnimv116F2ky0BF/R6aimEt5wHSs
LnacUrVxhjs2Rh9AfPUopHQ6Um/GkXH2CPfUZFxvPZgt3xpflBMxf/wCm9uciky2
en8HqHTXGETuDzJFGXr684gdrR0K3j/i9J10Ub83nUhHDnGcDfYSNTfYkl9DYSiF
bK34qdtOp3jmkTkce4x6VVSQnX+vf6EyTn0kOZ4qRMd7IeoQqlAylCHZQwn0gcK3
tmVIwM6Q6vsU3ZANkt7D
=Gyla
-----END PGP SIGNATURE-----

--moq0KUGrMOL5kiipj4Dg3vpEmsw4ULWkN--