Hi Anatol,

On Wed, Oct 19, 2016 at 1:41 AM, Anatol Belski <anatol....@belski.net> wrote:
> AFM the patch is not acceptable for 7.0. It is true that some place was moved 
> to the new random int functionality (in password AFAIR). But, it is done at 
> the place and the way that a BC breach is unlikely. Using the throwing 
> variant is for sure a BC breach, but also the way pushing while being 
> explicitly asked to go through an RFC, is inappropriate. As the new random_* 
> functions are available and allow to implement the best possible uniqueness 
> in user land, changing the algorithm of the existing uniqid() doesn't look to 
> have a valid base.

Any additional error could be BC. It's the fact.

However, your sentence does not make sense at all.
Do we revert any error emitting bug fix? No, not at all.

We do  add errors as normal bug fix process. Many of them are w/o RFC,
even w/o discussion.

Example: https://bugs.php.net/bug.php?id=73238
This bug fix caused WordPress caused 3 additional E_WARNING displayed
that can be remove by php.ini or code fix.

Which is important?
 - uniqid() is not unique
 - Really broken system that shouldn't be used may emit error

"/dev/urandom cannot read discussion" is FUD and irrelevant to this
discussion. Issues with user script random_bytes() implementation or
like does not apply to uniqid() fix.

Anyway, are we going to revert anything emit new errors from now on
because it's BC?
Are we going to require RFC for this kind of very simple and reasonable fix?
I hope not.

IMHO my discussion is logical. Please consider revert the revert.
Otherwise, we cannot fix even simple bugs.


Yasuo Ohgaki

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to