"Sure it's broken, but at least it's consistently broken!"

There are appropriate channels to discuss whether or not it is fundamentally broken or simply non-standard. You don't break userland code without those discussions.

It is fundamentally broken if you claim to implement an specific algorithm in a "non-standard" way that produces different of output. If you want to implement a different algorithm, call it by another name. This is why the PHP development team isn't taken seriously; they disregard proper knowledge of their profession in a cavalier way, lacking basic reading comprehension, due diligence and sanity.

It is broken, since the values don't match what is in mt19937ar.c. That's not in question.
Changing the (mis)behaviour without discussion: that is what's questionable here.

@it @salathe the pull request has been there for monthes.. I don't understand why you don't give the idea then, now complaint it was committed without discussion? (with whom? with you?)

@laruence I don't normally look through commits for breaking changes because normally they hit the mailing list. I just happened to see this yesterday.

It's a breaking change. It definitely does not belong in the 7.0 branch.

You may, as you state on the PR, find it weird that people might rely on a predictable stream of pseudo-random numbers, but they do have their uses.

@it okey, thanks, then may ,as this is really typo, leave the fix in master, and add a note in changlog, it is much better then only reverting this, thanks

@laruence I want to see this change (not the revert), don't get me wrong. With my documentation hat on, a heads up wouldn't go amiss.

As for why comment now? I don't watch the php-src PRs, so missed it there and only came now as it was linked in a place I do watch. Sorry if that's not good enough for you. That said, I did see the original commit (not the revert) email, and inwardly applauded the change.

@lt "You may, as you state on the PR, find it weird that people might rely on a predictable stream of pseudo-random numbers, but they do have their uses."

I'd like to know a use case in which someone would rely on that. Just out of curiosity.

I'd like to know a use case in which someone would rely on that. Just out of curiosity.

Maze generation is one example: if you want "levels" of maze, a simple way to do that is to seed the RNG with a particular number that generates a subjectively "easy" or "difficult" maze. The seeds then correspond to the level numbers, reducing storage of the level information by orders of magnitude.

In case your code needs a reproducable sequence of pseudo-random numbers, why not just hash your seed? If you need more numbers, hash the resulting hash (and so on). They will never change, not even when changing the environment/language/whatsoever.

Relying on the predictability of a pseudo-random number generator looks like bad style for me.

In case your code needs a reproducable sequence of pseudo-random numbers, why not just hash your seed? If you need more numbers, hash the resulting hash (and so on). They will never change, not even when changing the environment/language/whatsoever.

Wouldn't you then just write your own hash-based PRNG?
PRNGS are standardized, just as hash functions are. Why would the latter be less prone to typos than the former?

@koraa You're right, you would.
But if PRNGs are standardized, shouldn't we get PHPs PRNG to that standard?
Ok, well, we should keep providing the old one, that's right.

This is pure internet gold. Don’t ever change, PHP team. We need some fun in our lives.

please leave it broken, so i can continue pissing on about how bad php is.

Please don't use this procedure for the next security fixes if somebody comes up with an obscure use case that relies on a security bug. :D

Also:
The public api does not change,
the method is still producing the results as expected and as described in the documentation,
and
http://php.net/manual/en/function.mt-srand.php even mentions that its NOT SAFE to rely on the sequences.

< irony >
This was by far the best idea ever - to further encourage people to count on the predictability of so-called "random numbers"
< /irony >

Feels like re-inventing register_globals because that's what people were used to.

I've backported the mt_rand_value.phpt test so that we actually have tests checking what mt_rand outputs. However, the backported version tests that it always produces the wrong result:

a50c31d

This discussion makes it seem like some people think that this is a random number generator for cryptographic purposes, but it's not. So stay calm.

This is why I don't use PHP.

...

Well, it's part of the reason.

Andreas ist right and there no "other Channels".. it's fucked up.
"There are appropriate channels to discuss " : No... it's brocken. Thanks...

Well, at least there are laughs all throughout germany now: http://blog.fefe.de/?ts=a83b3c21

Yes, it's a buggy implementation, but we can't fix this in a patch release, there's a risk of backwards-compatibility breakage. It doesn't really matter if it doesn't match Mersenne Twister to existing apps. They just care if it works predictably. If we suddenly fix it in a patch release, we might break existing apps.

You break shitty code... I dont think this is a problem if the other code will work even better.

Uh, what? Expecting the RNG to work predictably is reasonable behaviour.

I just want to show my appreciation for the language maintainers here as a very heavy user of PHP and part of a team that maintains a huge amount of legacy code. I'm glad that I can continue to allow security and other non-BC changing updates to happen automatically and I can check the change logs only when doing major version updates. I need this level of stability and maturity in a language instead of having small things subtly break in code I've never read and don't understand and me wasting days wondering why, or weeks trying to rewrite, all while the business continues to suffer.

I expect diffrent values...

I see some people in this thread don't even understand the difference between a CSPRNG and mersenne twister and are just here to repeat that meme that "php is bad" without even understanding what the issue really is about.

Hint: it's not security sensitive, and the reverted fix didn't make the generated sequences any less predictable. That's not even relevant.

It could break legacy code.
I would rather say show that this kind of code really exists. code search, guides, whatever. This would be such a legacy code that might even break when changing platforms 32->64bit.
Otherwise, thanks for maintaining such a large codebase, and just fix it right by applying the patch.

Well, we don't know. Most code isn't open-source.

Also, another possible thing that will break is unit tests.

Though using GitHub and Open Hub Code Search, I couldn't find a single non-phpt usage of mt_srand. I could find usages of srand, but they all seem to use microtime.

MT rand should be "MT rand" otherwise it is not MT rand simply.
Anyway, I sent mail to internals. Let's discuss what we should do for released versions there.

at least, remember to fix it in 7.1.

inb4 "php_mt_rand()" polyfill

If you are "depending" (quoting the original comment here) on 'random', you are doing it wrong. Random should be unexpected, therefore undependable.

For backwards compatibility purposes, generally what matters isn't whether you ought to depend on something, but whether existing code actually does.

But how much do you want to keep functionality just for BC and sacrifice fundamental fixes.
Its it worth not making progress in a better code base, because it might break your ancient code ?
Just add it to the list http://php.net/manual/en/migration70.incompatible.php

Randomness of PHP mt_rand() is verified and it's supposed to be the same quality as original one. Games need the same random sequence on occasions, for example. If we are going to "fix" this, we should have INI switch for this. BTW I'm +1 for fixing this.

For the record, someone is already working on an RFC which will fix this issue, as well as a slew of other problems with the non-cryptographic PRNGs in PHP.

I added side-by-side BigCrush test results for MT19937 and mt_rand() to this gist.

Why not just add a behavior flag to the end that defaults to the original value? Won't that solve everyone's problem?
mt_rand(min, max, usef*upresult = true);
If you want the new way, set it to false or name the parameter the inverse, etc. Whatever makes everyone happy.

Why did you come here to comment on an old commit, to suggest something that was done years ago? Please don't.

@sammcbride

Why not just add a behavior flag to the end ...?

It makes no sense to switch algorithm on a per-fetch basis so the algorithm is set by mt_srand().

All sorts of problems have been suggested for mt_rand. A good cryptographic-strength alternative is:
$bytes = random_bytes(4); // Choose desired number of bytes of precision
$hex = bin2hex($bytes);