Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94446
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender)
To: Leigh <leight@gmail.com>, Pierre Joye <pierre.php@gmail.com>
References: <CAPwsocEihGOWC5_KX_FFe36dKTdSob0FFJUKuQW+u53QyeqgsQ@mail.gmail.com>
 <CAEZPtU7AzLGbFh+=bvJNA+HScLVuKsUuF9iUEhACL6xv7VRZ-w@mail.gmail.com>
 <CAPwsocF0Zty7Kp1FZHYA2h+Y+eJvypj9nt1OPa8fdEZdiqR8vw@mail.gmail.com>
 <CAEZPtU48mLGqVVh4sDguto4Vx9Kj+ec=ViTUWXOr-UXCgSt2KA@mail.gmail.com>
 <CAEZPtU6XUGM4BfQ5g+huV_=rrVPfFtpmSO+3CzTcXPC20+x2=g@mail.gmail.com>
 <CAPwsocE5v7mGt3frjoPeFyt6sWtvkjWb=zcPUhFuRLA8fXLY2g@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <b5e33d93-c815-5d45-4e71-f6fa3270004f@gmx.de>
Date: Sat, 9 Jul 2016 11:16:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAPwsocE5v7mGt3frjoPeFyt6sWtvkjWb=zcPUhFuRLA8fXLY2g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][VOTE] RNG fixes
From: cmbecker69@gmx.de (Christoph Becker)

On 09.07.2016 at 10:18, Leigh wrote:

> On Sat, 9 Jul 2016 at 08:48 Pierre Joye <pierre.php@gmail.com> wrote:
> 
>> So, I voted no then as it is clear that you do not see a problem to
>> break codes without a single warning or time to adapt before.
>>
>> The other sections are fine and voted yes.
> 
> For the part where you voted no. Still nobody has presented (publicly
> available) source that makes legitimate use of mt_srand (yes it's mt_srand
> that is "broken" here, not mt_rand) for deterministic streams of random
> numbers. I can only assume by this that almost nobody does. However, for
> those that do, they can still use the old algorithm.
> 
> For all of the other sections where you voted yes, they are mostly bug
> fixes, but all change the output of mt_rand AND more functions (without a
> single warning, like you wanted). I'm not trying to encourage you to change
> any votes, but I need to make sure you understand what you're voting for.

Thanks, Leigh, for the RFC.

In my opinion, all sections except "Alias rand() to mt_rand()" and maybe
"Make array_rand() more efficient" are *bug* *fixes*, and even though
they might cause BC breaks, deploying them with a minor release seems to
be a sensible compromise.

Aliasing rand() to mt_rand() should better be postponed to PHP 8.0 (if
at all).  I'm aware of rand()'s limitations and platform specific
behavior, but I'd prefer to leave the choice to nonetheless use it to
userland (at least for now).  I would suggest to improve the
documentation of rand() wrt. to the note in the description section and
the warning in the notes section (which are mutually contradicting
themselves).

Assuming that "Make array_rand() more efficient" is indeed only about
performance (and not about fixes for the broken implementation), it
wouldn't be a bug fix, but as array_rand()'s behavior would change
anyway as noted by the RFC, it makes sense to do it as well.

-- 
Christoph M. Becker