BC break with rand() where min > max

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

Leigh,

I would very much prefer to keep this BC. If we do the right thing, and
there are no repercussions, I'd actually remove the warning. If you think
we might want to disallow this in the future, use an E_DEPRECATED, but a
warning seems pointless unless it's doing the wrong thing, or it's going to
start doing the wrong thing at some point.

• Davey

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

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