Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocH7t6XQaN8p-q3pMj4v55VTh15k5RoT5LUKFb9TeucrPg@mail.gmail.com>
References: <CAPwsocH7t6XQaN8p-q3pMj4v55VTh15k5RoT5LUKFb9TeucrPg@mail.gmail.com>
Date: Mon, 8 Aug 2016 19:12:09 -0300
Message-ID: <CAEsg9X2S+MKjwKkVqJ=YR=KDy4J=_-veOmA3xVSmx-3HDsnuZQ@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] BC break with rand() where min > max
From: david.proweb@gmail.com (David Rodrigues)

What is the sense to use min > max, in general?
It should 'flip' arguments automatically in this case?

2016-08-08 18:36 GMT-03:00 Leigh <leight@gmail.com>:
> 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



-- 
David Rodrigues