Hi! > * Get rid of rand(), srand() and getrandmax() * Rename mt_rand(), > mt_srand() and mt_getrandmax() to rand(), srand(), and getrandmax() > but add mt_* aliases for backwards-compatibility
This means rand() and mt_rand() would do the same. That however assumes that OS's libc random-number functions are and will always be inferior. Is that the case that we believe? In any case, I would rather disclaim any specifics about implementation of rand() other than saying it is using best algorithm we have. If we decide MT one is the best we can support, so be it. > * Make mt_srand() > and srand() do nothing and produce a deprecation notice I think this is not a good idea. While we can not guarantee the PRNG we use always provides the same values for the same srand on every system for every version, it is the case that it provides them in the same environment, thus enabling the possibility of testing random-driven algorithms. Disabling it precludes any such testing, except with user-level workarounds, which will inevitably be more brittle and error-prone. This all is for no observable gain. * Use a > 64-bit random number generation algorithm on 64-bit platforms (or > invoke the 32-bit generator twice) This sounds like a good idea, though it may have BC implications. Is there a use case we know of where it matters? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
