Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94185
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
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>
Message-ID: <8b48f847-bbba-03f8-4b2e-9cd0841b484e@gmail.com>
Date: Tue, 21 Jun 2016 22:40:51 +0100
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: <2f92fa26-5f50-0e68-c1fc-de79f17c201e@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] RNG fixes
From: rowan.collins@gmail.com (Rowan Collins)

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!

On 21/06/2016 18:37, Fleshgrinder wrote:
> I don't understand the drive to holding on to obviously faulty stuff.
> Nikic proposed already to deprecate rand() and I am only saying that we
> can go one step further and implement pcg_rand() in favor of mt_rand()
> and deprecate mt_rand(). Probably not something we want to do in 7.1
> (because PCG needs some more time to mature) but something that we might
> want to do on the road to PHP 8.0.

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,

-- 
Rowan Collins
[IMSoP]