Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0e4655b3-d0cb-f1cc-6e39-c336ed51e2de@gmail.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>
 <CAF+90c9N3Mk99OOhLi_NgM6GKYhh0a5gXk2nH1fmnyqz=f0Zbw@mail.gmail.com>
 <D3915644.6FA67%fsb@thefsb.org> <CAF+90c9sONJVu6BFafM8h9DKOK6eaj+xsk_Jt3kd-DTVBVn6Fg@mail.gmail.com>
 <a8471ece-05e2-ec5b-c3b2-2484b6da4675@gmail.com> <0e4655b3-d0cb-f1cc-6e39-c336ed51e2de@gmail.com>
Date: Fri, 24 Jun 2016 08:35:56 +0700
Message-ID: <CAEZPtU5pmAoRJ15f=WE6+rDbEimhSVo3Ln3Vk27huWRLb_N00g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] RNG fixes
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev
<smalyshev@gmail.com> wrote:
> Hi!
>
>> I would prefer something like random_fast_int() == mt_rand() == rand(),
>> with clear documentation on when to use random_fast_int() instead of
>> random_int(), and a note on the others that "since 7.2, mt_rand() is an
>> alias for random_fast_int()" etc. (Not wedded to the name
>> random_fast_int, we can bikeshed that later.)
>
> That sounds to me like a good way to proceed too. I don't think it's a
> big deal it mt_rand won't be using specific MT algorithm anymore, I see
> very small number of places where it would matter.
>
> One thing to consider is that there might be test scenarios, sequences,
> etc. that depend on specific seed and will be broken by changing the
> implementation (tests relying on specific rand are not the very best
> idea, but they do happen), but I think this kind of thing may be
> acceptable for a major version. Would like to hear thoughts on this though.

fast_int or fast whatever looks bad to me. But we know that.

Also, about mt_rand, it costs nothing to have a compat mode for the
cases where the current (standard or not is not relevant)
implementation is being relied on.

More generally about the random APIs, there are many good non crypto
safe RNGs, and there will be more. Each of them have their own use
cases. I do not think that arbitrary choose, change, actualized them,
in major versions or not, is a good thing.

I would rather prefer to have a more flexible API allowing to choose
one algorithm for a run. It is also good to have a default per
category (strong, weak, fast for example) so one can use the current
default for a given need.

A good API for RNG is https://bitbucket.org/haypo/hachoir/wiki/Home.
It allows flexibility while having default and the ability to choose a
specific implementation if desired. My main point is to do not
penalize valid uses because some code will never ever do the right
thing (tm). A language cannot prevent bad behaviors but do not have to
punish good cases by removing useful features for the "good of all".

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org