Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95003
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.99 as permitted sender)
To: Leigh <leight@gmail.com>, internals@lists.php.net
References: <CAPwsocH7t6XQaN8p-q3pMj4v55VTh15k5RoT5LUKFb9TeucrPg@mail.gmail.com>
Message-ID: <069eeb79-5fa7-0c52-515c-8be836d6fce2@thefsb.org>
Date: Wed, 10 Aug 2016 09:18:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAPwsocH7t6XQaN8p-q3pMj4v55VTh15k5RoT5LUKFb9TeucrPg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: BC break with rand() where min > max
From: fsb@thefsb.org (Tom Worster)

On 8/8/16 5:36 PM, Leigh wrote:
> Hi all,
>
> There has been an unforeseen break with rand() when the minimum value is
> greater than the maximum.
>
> Prior to 7.1 rand() would happily accept backwards parameters and return a
> value, however in the 7.1 branch it now emits a warning and returns false.
>
> I've preemptively committed a fix to allow min > max and return a value as
> in previous versions, but have kept the warning.
>
> Looking for some feedback/opinions on whether anyone else thinks this
> should be fixed differently (or not at all).
>
> N.B. this also changes the behaviour of mt_rand to now accept min > max

Your fix seems fine for rand() but less so for mt_rand().

Applying this fix will break much less mt_rand()-using code than not
applying it will break rand()-using code. From that point of view,
applying it is the better choice.

Otoh, it's like copy-pasting a weird old bug from rand() to mt_rand().
The plan was to make rand() alias mt_rand(). Now I'm not sure that's a
smart plan.

Tom