Hi, >>>> IMO, improving it (generate better semi-unique ID) is not important >>>> enoungh to introduce unnecessary BC break. (Why returning string length >>>> is changed?) >>> >>> It cannot not produce unique ID by default as name "uniqid()" implies. >>> Reason is described in the RFC. Please read RFC because it's the >>> official proposal. >> >> I had read it, of course. But I could not understand why you chose BC >> break way. > > IMHO, 10 bits (about a million) entropy is not considered enough > entropy, do you?
Do you say about extra part which is added by "more_entropy" option? Current "more_entropy" part (10 bytes) pattern is "n.nnnnnnnn" and its variation is 10^9 (1 billion) as written in your RFC. (about 30bits?) I think it is enough to avoid collision in the same usec, for non-security purpose. > How serious BC is? You should already know that this BC-breack breaks existing valid PHP codes in some situation. (DB error, test failure, etc.) BC-breack may be acceptable if the change is clearly greate improvement or obviously necessary. But this change is not, I think. > It's much less impact than using mt_rand() all over > the code. i.e. rand() and mt_rand() is predictable random generator. Sorry, I cannot understand what you say... (Why mt_rand?) -- Kazuo Oishi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
