Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Tue, Sep 13, 2016 at 1:20 PM, Kazuo Oishi wrote: > The uniqid() manual explicitly say, > > - default value of more_entropy is false > > - the returned string will be 13 characters long. If more_entropy is >TRUE, it will be 23 characters. > > - if more_entropy

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi, > Actually not with current implementation. If time is rewined, the same ID > could be generated by chance. Because, both ID part and entropy part > is generated based on the current system time. Collision would be rare, > but it's not rare as it should be at all. > > I think minimum would be

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Tue, Sep 13, 2016 at 11:48 AM, Yasuo Ohgaki wrote: >> Current "more_entropy" part (10 bytes) pattern is "n." 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,

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

On Tue, Sep 13, 2016 at 11:23 AM, Kazuo Oishi wrote: > 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

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

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

[PHP-DEV] Session Security manual page is updated

Hi all, I've updated session security manual page a lot. http://php.net/manual/en/session.security.php Some of us do not realize importance of non adoptive session management and timestamp management. e.g. https://wiki.php.net/rfc/precise_session_management

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

On Tue, Sep 13, 2016 at 10:14 AM, Yasuo Ohgaki wrote: >> I use `uniqid()` daily in my test suites, even new ones (not much else), and >> introducing the `.` everywhere will just cause issues. >> Changing string length may also break everything. > > It seems you have code that

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Marco, On Mon, Sep 12, 2016 at 11:48 PM, Marco Pivetta wrote: > > Full ACK on what Kazuo said. > > I use `uniqid()` daily in my test suites, even new ones (not much else), and > introducing the `.` everywhere will just cause issues. > Changing string length may also break

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Mon, Sep 12, 2016 at 11:46 PM, Kazuo Oishi wrote: >>> 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

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Rowan, On Mon, Sep 12, 2016 at 10:47 PM, Rowan Collins wrote: > > uniqid() has never been, and is not claimed to be, guaranteed unique to any > particular standard. Right. We need to improve documentation. It only has crypt related usage warning now. > On 12/09/2016

Re: [PHP-DEV] Modern practices ...

On Tue, Sep 13, 2016 at 3:06 AM, Lester Caine wrote: > On 12/09/16 20:31, Christoph M. Becker wrote: >> On 11.09.2016 at 12:35, Lester Caine wrote: >> >>> On 11/09/16 11:05, Christoph M. Becker wrote: >> >>> I have already debugged the problems and will tidy up the notes later

Re: [PHP-DEV] RFC - Immutable classes

On 09/12/2016 06:47 PM, Stephen Reay wrote: Ah, I did see that one, but there was a lot of discussion after it so I thought the idea evolved. Response below based on skimming the responses after that as well... It sounds like there's more that needs to go on, though. It sounds like that

RE: [PHP-DEV] merged branches in incorrect order

> To keep it clean, you can > > git checkout master > git reset --hard origin/master > > and same for every branch containing a wrong merge. This will reset every branch to the state of remote, after that you can repeat the merge clean way. Yes, but in this case, I'd already pushed.

Re: [PHP-DEV] RFC - Immutable classes

Hi Larry, > On 13 Sep 2016, at 03:11, Larry Garfield wrote: > > On 09/12/2016 11:40 AM, Fleshgrinder wrote: >> On 9/11/2016 10:04 PM, Larry Garfield wrote: >>> On 09/10/2016 05:55 AM, Fleshgrinder wrote: @Larry what do you think about the CoW proposal? >>> I'm

RE: [PHP-DEV] merged branches in incorrect order

Adam, > -Original Message- > From: Adam Baratz [mailto:adambar...@php.net] > Sent: Monday, September 12, 2016 11:54 PM > To: internals@lists.php.net > Subject: [PHP-DEV] merged branches in incorrect order > > I was following https://wiki.php.net/vcs/gitworkflow to make my first commit >

Re: [PHP-DEV] merged branches in incorrect order

Hi! On 9/12/16 2:53 PM, Adam Baratz wrote: > I was following https://wiki.php.net/vcs/gitworkflow to make my first > commit to ext/pdo_dblib. I made a little mistake. I committed first to > PHP-7.0. I forgot about the PHP-7.1 branch and merged from PHP-7.0 to > master. I went back and merged from

[PHP-DEV] merged branches in incorrect order

I was following https://wiki.php.net/vcs/gitworkflow to make my first commit to ext/pdo_dblib. I made a little mistake. I committed first to PHP-7.0. I forgot about the PHP-7.1 branch and merged from PHP-7.0 to master. I went back and merged from PHP-7.0 to PHP-7.1. All merges applied cleanly, but

RE: [PHP-DEV] Re: VCS Account Request: adambaratz

> -Original Message- > From: Adam Baratz [mailto:adambar...@php.net] > Sent: Sunday, September 11, 2016 9:37 PM > To: Ferenc Kovacs > Cc: PHP Group ; PHP Internals > Subject: Re: [PHP-DEV] Re: VCS Account Request: adambaratz >

Re: [PHP-DEV] RFC - Immutable classes

On 09/12/2016 11:40 AM, Fleshgrinder wrote: On 9/11/2016 10:04 PM, Larry Garfield wrote: On 09/10/2016 05:55 AM, Fleshgrinder wrote: @Larry what do you think about the CoW proposal? I'm afraid I got lost in the thread somewhere with the back and forth about implementation details. Can you

Re: [PHP-DEV] Modern practices ...

On 12/09/16 20:31, Christoph M. Becker wrote: > On 11.09.2016 at 12:35, Lester Caine wrote: > >> On 11/09/16 11:05, Christoph M. Becker wrote: > >> I have already debugged the problems and will tidy up the notes later >> when I cross check things. This is the sort of support I've always >>

Re: [PHP-DEV] Modern practices ...

On 11.09.2016 at 12:35, Lester Caine wrote: > On 11/09/16 11:05, Christoph M. Becker wrote: > I have already debugged the problems and will tidy up the notes later > when I cross check things. This is the sort of support I've always > provided to the PHP project. The pages relating to the

[PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

> > It is NOT insulting to say that people who still insist on using command > line tools are living in the past for the simple reason that the command > line interface was replaced with the GUI when the Windows OS was released > in the 1990s. That is 25 years ago. Is that in the past or what?

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-09-12

Results for project PHP master, build date 2016-09-12 06:25:06+03:00 commit: ca5cfac previous commit:fd5f0e4 revision date: 2016-09-12 00:08:16+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] RFC - Immutable classes

On 9/11/2016 10:04 PM, Larry Garfield wrote: > On 09/10/2016 05:55 AM, Fleshgrinder wrote: >> @Larry what do you think about the CoW proposal? > > I'm afraid I got lost in the thread somewhere with the back and forth > about implementation details. Can you repost the current proposal, or > has

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

On Mon, Sep 12, 2016 at 4:46 PM, Kazuo Oishi wrote: > 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

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

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

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Yasuo, uniqid() has never been, and is not claimed to be, guaranteed unique to any particular standard. On 12/09/2016 13:08, Yasuo Ohgaki wrote: Since we have to change "more entropy" to TRUE by default Is your intention that the version without "more entropy" be deprecated, and at

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, Sep 12, 2016 at 1:51 PM, Nikita Popov wrote: > On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs wrote: > >> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote: >> >> > On Mon, 12 Sep 2016, Pierre Joye wrote: >> > >> > > This RFC

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi, On Sep 12, 2016 5:48 PM, "Kazuo Oishi" wrote: > > Hi, > > > I know some code breaks, but it's not many. It's not fatal BC also. > > > > IMHO, uniqid() should try to generate uniqid() possible. uniqid() does produce > > non unique ID because it is system time based. This

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

On Mon, Sep 12, 2016 at 9:08 PM, Yasuo Ohgaki wrote: > It cannot not produce unique ID as name "uniqid()" implies by default. It cannot not produce unique ID by default as name "uniqid()" implies. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Mon, Sep 12, 2016 at 7:48 PM, Kazuo Oishi wrote: >> I know some code breaks, but it's not many. It's not fatal BC also. >> >> IMHO, uniqid() should try to generate uniqid() possible. uniqid() does >> produce >> non unique ID because it is system time based. This

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 12, 2016 6:51 PM, "Nikita Popov" wrote: > > On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs wrote: >> >> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote: >> >> > On Mon, 12 Sep 2016, Pierre Joye wrote: >> > >> > > This RFC is

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs wrote: > On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote: > > > On Mon, 12 Sep 2016, Pierre Joye wrote: > > > > > This RFC is about stop bundling it with the php releases and propose > > > composer/pickle

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans wrote: > On Mon, 12 Sep 2016, Pierre Joye wrote: > > > This RFC is about stop bundling it with the php releases and propose > > composer/pickle instead. Everything else has nothing to do with this > > RFC (aka web frontend, what

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 12, 2016 3:24 PM, "Stanislav Malyshev" wrote: > > Hi! > > >> PEAR/PECL as a package manager has historically had little utility to the > >> average user apart from installing those PECL extensions which aren't > >> packaged by a particular user's distribution

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, Sep 12, 2016 at 10:24 AM, Stanislav Malyshev wrote: > Hi! > > >> PEAR/PECL as a package manager has historically had little utility to > the > >> average user apart from installing those PECL extensions which aren't > >> packaged by a particular user's distribution

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston wrote: > Sent: Sunday, September 11, 2016 11:44 AM > >To: Tony Marston > >Cc: Stanislav Malyshev ; internals@lists.php.net > >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with > composer/pickle > > > >On Sun,

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi, > I know some code breaks, but it's not many. It's not fatal BC also. > > IMHO, uniqid() should try to generate uniqid() possible. uniqid() does produce > non unique ID because it is system time based. This change mitigates impact of > misuse also which is common in both open and close codes.

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

2016-09-12 10:21 GMT+02:00 Derick Rethans : > On Mon, 12 Sep 2016, Pierre Joye wrote: > > > This RFC is about stop bundling it with the php releases and propose > > composer/pickle instead. Everything else has nothing to do with this > > RFC (aka web frontend, what happens or not

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Hi! > It's curious to see though that the off-topic comments get replies, but > few real concerns do from the RFC author - such as not removing > something before we have a confirmed alternative. I'd like to trial > pickle first for a few releases and only then see whether to remove the >

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

I think Derick has a good point here. I agree on the part that we should stop bundling PEAR/PECL, but we might be rushing into pickle too fast. 2016-09-12 10:21 GMT+02:00 Derick Rethans : > On Mon, 12 Sep 2016, Pierre Joye wrote: > > > This RFC is about stop bundling it with the

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Hi! >> PEAR/PECL as a package manager has historically had little utility to the >> average user apart from installing those PECL extensions which aren't >> packaged by a particular user's distribution repository. Certainly hasn't >> had any real viability in years. Trying to replace something

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Mon, 12 Sep 2016, Pierre Joye wrote: > This RFC is about stop bundling it with the php releases and propose > composer/pickle instead. Everything else has nothing to do with this > RFC (aka web frontend, what happens or not on pear.php.net, its > packages, etc.). > > To all: please re

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sun, 11 Sep 2016, Sherif Ramadan wrote: > On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston > PEAR/PECL as a package manager has historically had little utility to the > average user apart from installing those PECL extensions which aren't > packaged by a particular

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 12, 2016 2:36 PM, "Tony Marston" wrote: > > Sent: Sunday, September 11, 2016 8:32 PM > >To: Tony Marston ; Stanislav Malyshev ; internals@lists.php.net > >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > > > > >On 09/11/2016 10:47

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Sent: Sunday, September 11, 2016 8:32 PM >To: Tony Marston ; Stanislav Malyshev ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > >On 09/11/2016 10:47 AM, Tony Marston wrote: >> Sent: Saturday, September 10, 2016 7:47 PM >>> To: Tony

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Sent: Sunday, September 11, 2016 11:44 AM >To: Tony Marston >Cc: Stanislav Malyshev ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > >On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston wrote: > >Sent: Saturday,

Re: [PHP-DEV] RFC - Immutable classes

@Larry RFC is not updated with the solution for cloning yet. So far I did add changes on which we have agreed on. Currently we have to candidates: First one is to have copy on write (As Christoph pointed out, we had that in PHP 4). Second proposal is to introduce "transformer" keyword as a

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi Kazuo, On Mon, Sep 12, 2016 at 1:41 PM, Kazuo Oishi wrote: > >> This is RFC for improving uniqid() uniqueness. >> https://wiki.php.net/rfc/uniqid >> >> PR >> https://github.com/php/php-src/pull/2123 >> >> If there is anything left to discuss, please comment. > > I think