Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95968
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain giraffy.jp designates 49.212.134.110 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals\@lists.php.net" <internals@lists.php.net>
In-Reply-To: <CAGa2bXYeWZSx2vOYPhnCJ_O7ry2jPNNPcm=mpNuVJAwYAY5sMA@mail.gmail.com>
	(Yasuo Ohgaki's message of "Tue, 13 Sep 2016 10:13:41 +0900")
References: <CAGa2bXYg1kkoYGQNr8T2oTshuqrvweefYO+EdY41w1vwUM32iQ@mail.gmail.com>
	<878tuxenl4.fsf@lil.giraffy.jp>
	<CAGa2bXaTydTSZniX4dUA9h_FcNaymyqfDXQJO0zx1ZDfLmvWdg@mail.gmail.com>
	<87twdlcs2j.fsf@lil.giraffy.jp>
	<CAGa2bXaziNMtNAgsJgX-BCgLL9z2WkoSaP8aNVrAgwo9MJ4WEQ@mail.gmail.com>
	<87h99lch13.fsf@lil.giraffy.jp>
	<CAGa2bXYeWZSx2vOYPhnCJ_O7ry2jPNNPcm=mpNuVJAwYAY5sMA@mail.gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Date: Tue, 13 Sep 2016 11:23:09 +0900
Message-ID: <877fagczci.fsf@lil.giraffy.jp>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness
From: kazuo@o-ishi.jp (Kazuo Oishi)

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