Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94215
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <65ea0142-c2d6-f4ed-e98e-b7c7fbc51c58@fleshgrinder.com>
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> <65ea0142-c2d6-f4ed-e98e-b7c7fbc51c58@fleshgrinder.com>
Date: Wed, 22 Jun 2016 23:19:11 +0200
Message-ID: <CAF+90c9N3Mk99OOhLi_NgM6GKYhh0a5gXk2nH1fmnyqz=f0Zbw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, Tom Worster <fsb@thefsb.org>
Content-Type: multipart/alternative; boundary=94eb2c07b82a2fd6990535e47d2b
Subject: Re: [PHP-DEV] [RFC] RNG fixes
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c07b82a2fd6990535e47d2b
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 22, 2016 at 7:46 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 6/21/2016 11:40 PM, Rowan Collins wrote:
> > Hi,
> >
> > 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!
> >
> > 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.
> >
> > 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
> possible.
> >
> > 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 =
> > random_int_sequence($user_seed, 0, 10); $user_pick = $user_seq();" Or
> > maybe it could return a closure, or an object - either way, something to
> > replace the global state of (mt_)srand.
> >
> > 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.
> >
> > 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...
> >
> > 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
> thing.
> >
> > Regards,
> >
>
> Yes, yes, yes! :)
>
> I would still like to deprecate rand() but probably leave it to Nikic
> because people actually listen to him. ;)
>

I haven't been following this thread, just jumping in to comment on this
point. My suggestion to deprecate rand() was motivated by the fact that
rand() produces extremely low quality random numbers on Windows, while at
the same time having the name people are most likely to try first if they
want to have a random number. It's a bad state of things if there's a
rand() and an mt_rand() function and the latter is preferable in *all*
situations, while the former is more likely to be used. However, this
concern is completely alleviated by aliasing rand() to mt_rand(). If we do
this, I see no reason to deprecate rand(), at least in the short term.

Btw, I fully support this RFC.

Nikita


>
> @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 = 0, ?int $max = PHP_INT_MAX): int;
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

--94eb2c07b82a2fd6990535e47d2b--