Re: [RFC][DISCUSSION] Improve uniqid() uniqueness
| From: | Kazuo Oishi | Date: | Tue, 13 Sep 2016 02:23:09 +0000 |
| Subject: | Re: [RFC][DISCUSSION] Improve uniqid() uniqueness | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95968@lists.php.net to get a copy of this message | ||
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