Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91358
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbOzvryXAnwBGFCVvfKOLqTDs8dLZK4FNLLKvnLL4i3VQ@mail.gmail.com>
References: <CAGa2bXaBoxMF9mpn0yjJ-sNZ+rYG=rpTB=iPP_t7RXsJGWafMQ@mail.gmail.com>
	<CAGa2bXbOzvryXAnwBGFCVvfKOLqTDs8dLZK4FNLLKvnLL4i3VQ@mail.gmail.com>
Date: Tue, 23 Feb 2016 19:46:18 +0700
Message-ID: <CAEZPtU4eRZt14PM1O8DTUA82ZqQpLR+oNA466ixZNcpDoLQf9w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: PRNG: Raise warning and/or provide better pseudo
 random generator?
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Tue, Feb 23, 2016 at 5:41 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi all,
>
> On Tue, Feb 23, 2016 at 6:30 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>> We have issue on pseudo random generators generates only odd/even
>> numbers.
>>
>> https://bugs.php.net/bug.php?id=63174
>> https://news.ycombinator.com/item?id=9941364
>>
>> We should raise E_WARNING/E_NOTICE if user supplies random number
>> range that generated random number cannot be random at least.
>> Patch for rand/mt_rand.
>> https://gist.github.com/yohgaki/1519f65dffd66735bafe
>>
>> It seems we need more reliable(fool proof) pseudo random generator.
>> Anyone working on this?
>>
>> We may extends rand()/mt_rand() so that they work with larger range by
>> calling random generators multiple times. If this is implemented, the
>> patch raises errors is not required. mt_rand() extension breaks compatibility
>> with other MT rand implementations, but we already broke it. Therefore, it
>> should not matter. (This was the reason why mt_rand() wasn't made to support
>> 64bit int, IIRC)
>>
>> IMO, we should provide better pseudo random generators than now.
>>
>> Any comments?
>
> This is edge case that produces odd/even numbers only.
> https://3v4l.org/kYpAF
> This is the worst case. Current implementation uses 32bit int for
> generating random numbers and any number exceeds the range could be
> biased because the result is computed by RAND_RANGE() which uses
> double for arithmetic. PHP allows huge min/max without any
> warning/error under 64bit OS.
>
> Limiting range can prevent this and we can be sure rand()/mt_rand()
> produce the same random numbers on both 32/64 bit platform. (If rand()
> uses the same algorithm, of course)
> https://gist.github.com/yohgaki/1519f65dffd66735bafe
> Valid range is limited to 2^31 according to current implementation.
>
> Actual range could be determined by PHP_RAND_MAX/PHP_MT_RAND_MAX, but
> I heard Windows' PHP_RAND_MAX is only 2^15. Is this correct? I don't
> prefer to have strict range error for these systems. I'll write patch
> that does not raise warning for smaller PHP_RAND_MAX. It's unreliable
> pseudo random generator anyway. It should not matter much.
>
>
> Any comments for adding out of range warnings to rand()/mt_rand()? If
> nobody has comment on this, I'll write RFC for additional warnings.
> Anyone prefer to extend rand()/mt_rand() for 64bit OSes?

Thing is the MT algorithm may not be design to do that, at all but was
designed for 32-bit integers. I won't be in favor of changing (again)
the implementation without any safety about the results (safety means
compliance or be even more different from the MT algorithms).

Adding warning when the given ranges are out of bounds sound good, and
reduce them within the maximum range.

I joined the other person proposing not to change anything else in our
MT implementation as there is little to no benefit.

If we need pure implementation of one pseudo RNG or another, we can
provide new implementations. But changing again this one may bring
more troubles than what we are trying to solve.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org