Hey, > On 12 Jan 2015, at 01:12, Stanislav Malyshev <smalys...@gmail.com> wrote: > >> * 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?
Quite possibly not, but we know that some OSes do have inferior rand() implementations and using our own ensures cross-platform uniformity. Using our own implementation shields users from sucky stdlibs. > 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. Yeah, I agree there. >> * 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. Such algorithms really shouldn’t be using rand() or mt_rand(), they aren’t fit for purpose for reasons I’ve previously elaborated. Code which needs to do what you’re describing should use an API made specifically for that purpose. There are userland packages for this. We could also add a standard library class like I suggested earlier. I don’t really see why a userland DRBG would necessarily be “brittle and error-prone”. Not unless they’re using some completely unmaintained library. > * 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? I can’t immediately think of one, but I can’t imagine there wouldn’t be a need for values larger than 2^32. By the way, I’m not sure what I’ll do for rand() for the bigint RFC/patch. I might just use the bigint library’s random function when the range is wider than that a native integer has, but I can’t do that if we allow seeding (because it breaks predictable sequence generation). Alternatively, I could just not make it work with bigints, since producing incredibly large numbers can of course be done manually with bitwise shifts and multiple mt_rand() invocations. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
