Re: [PHP-DEV] Inconsistent implementation of array sorting (old zend_qsort in array_multisort)

Hey: On Thu, Jun 23, 2016 at 5:04 PM, Benjamin Coutu wrote: > Hello everyone, > > While reviewing the array.c code base, I have noticed that the > array_multisort function still uses the old zend_qsort instead of the new > zend_sort algorithm that was introduced with PHP 7.

[PHP-DEV] Inconsistent implementation of array sorting (old zend_qsort in array_multisort)

Hello everyone, While reviewing the array.c code base, I have noticed that the array_multisort function still uses the old zend_qsort instead of the new zend_sort algorithm that was introduced with PHP 7. That represents a clear inconsistency, because all other array sorting functions utilize

Re: [PHP-DEV] ext/pcntl asynchronous sugnal handling

On Thu, Jun 23, 2016 at 2:19 PM, Dmitry Stogov wrote: > Hi, > > > Currently OS signals may be handled through ext/pcntl: > > - synchronously, calling pcntl_signal_dispatch() manually > > - asynchronously, if PHP scripts compiled with declare(ticks=N); > > > The simple patch uses

Re: [PHP-DEV] [RFC] RNG fixes

On 6/22/16, 5:19 PM, "Nikita Popov" wrote: >I haven't been following this thread, just jumping in to comment on this >point. My suggestion to deprecate rand() was motivated by the fact that >rand() produces extremely low quality random numbers on Windows, while at >the same

[PHP-DEV] ext/pcntl asynchronous sugnal handling

Hi, Currently OS signals may be handled through ext/pcntl: - synchronously, calling pcntl_signal_dispatch() manually - asynchronously, if PHP scripts compiled with declare(ticks=N); The simple patch uses the recently added into Zend Engine ability and allows asynchronous signal handling

[PHP-DEV] PHP 7.0.8 is available

Hi, The PHP development team announces the immediate availability of PHP 7.0.8. This is a security release. Several security bugs were fixed in this release. All PHP 7.0 users are encouraged to upgrade to this version. For source downloads of PHP 7.0.8 please visit our downloads page:

Re: [PHP-DEV] ext/pcntl asynchronous sugnal handling

> On 23 06 2016, at 14:28, Nikita Popov wrote: > > On Thu, Jun 23, 2016 at 2:19 PM, Dmitry Stogov wrote: > >> >> The simple patch uses the recently added into Zend Engine ability and >> allows asynchronous signal handling without extra ZEND_TICKs

Re: [PHP-DEV] [RFC] RNG fixes

On Thu, Jun 23, 2016 at 3:18 PM, Tom Worster wrote: > On 6/22/16, 5:19 PM, "Nikita Popov" wrote: > > >I haven't been following this thread, just jumping in to comment on this > >point. My suggestion to deprecate rand() was motivated by the fact that >

Re: [PHP-DEV] [RFC] RNG fixes

On 23/06/2016 14:57, Nikita Popov wrote: Whatever we do, please maintain the invariant that mt_rand() >= rand() in terms of quality. I recommend doing this by making mt_rand() == rand(). The relationship that I feel is poorly defined at the moment is random_int() vs mt_rand(). There isn't

[PHP-DEV] [Bug #68319] unserialize() with modified class definition.

https://bugs.php.net/bug.php?id=68319 https://3v4l.org/irnRC The crux is this: * Object instance gets serialized with one definition, maybe stored in DB/file, whatever, the serialized value lives on. * Class definition changes slightly. In this case, a property changes visibility. * Serialized

Re: [PHP-DEV] [RFC] RNG fixes

Hi! > I would prefer something like random_fast_int() == mt_rand() == rand(), > with clear documentation on when to use random_fast_int() instead of > random_int(), and a note on the others that "since 7.2, mt_rand() is an > alias for random_fast_int()" etc. (Not wedded to the name >

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

BTW: I'm not sure what pcntl_sigaction() could return as the "oldact" argument..., so may be the original proposal is good enough. From: Dmitry Stogov Sent: Thursday, June 23, 2016 9:02:55 PM To: PHP internals; bis...@php.net; Joe Watkins;

[PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

Hi All, David and I would like to propose a second array argument be added to signal handlers registered with pcntl_signal . The array passes through kernel-provided signal context like the process ID sending the signal.

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

Hi, To keep maximum compatibility and eliminate unnecessary additional overhead, I would keep pcntl_signal() unchanged, but add pcntl_sigaction() with the ability to specify the need for the second argument (In the same way as POSIX does). Joe, Davey, when we stop targeting new RFCs for 7.1?

Re: [PHP-DEV] [Bug #68319] unserialize() with modified class definition.

Hi! > Looking into the number of unserialize() related "security" issues, I > think we should fix all of them once and forever, introducing a > validation pass. > > In case something in provided data is wrong (e.g. duplicated properties > or array keys, unexpected types, invalid references,

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

On Thu, Jun 23, 2016 at 12:26 PM Dmitry Stogov wrote: > BTW: I'm not sure what pcntl_sigaction() could return as the "oldact" > argument..., so may be the original proposal is good enough. > -- > *From:* Dmitry Stogov > *Sent:*

Re: [PHP-DEV] [RFC] RNG fixes

On 6/23/16 12:56 PM, Stanislav Malyshev wrote: Hi! I would prefer something like random_fast_int() == mt_rand() == rand(), with clear documentation on when to use random_fast_int() instead of random_int(), and a note on the others that "since 7.2, mt_rand() is an alias for random_fast_int()"

Re: [PHP-DEV] [RFC] RNG fixes

On 6/23/2016 6:56 PM, Stanislav Malyshev wrote: > Hi! > >> I would prefer something like random_fast_int() == mt_rand() == rand(), >> with clear documentation on when to use random_fast_int() instead of >> random_int(), and a note on the others that "since 7.2, mt_rand() is an >> alias for

Re: [PHP-DEV] [RFC][Vote] Typed Properties

Le 10/06/2016 12:38, Joe Watkins a écrit : The vote for typed properties has been restarted. Hi, We, at AFUP, often tend to be on the "more static / strict types" side of things, and it remains this way for this RFC -- which means we would be +1 for typed properties. A few noted this

Re: [PHP-DEV] [RFC] RNG fixes

hi, On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev wrote: > Hi! > >> I would prefer something like random_fast_int() == mt_rand() == rand(), >> with clear documentation on when to use random_fast_int() instead of >> random_int(), and a note on the others that "since

Re: [PHP-DEV] [RFC] RNG fixes

On Fri, Jun 24, 2016 at 8:35 AM, Pierre Joye wrote: > hi, > > On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev > wrote: >> Hi! >> >>> I would prefer something like random_fast_int() == mt_rand() == rand(), >>> with clear documentation on when to use

Re: [PHP-DEV] [RFC] RNG fixes

On 6/22/2016 11:04 PM, Dan Ackroyd wrote: > On 22 June 2016 at 18:46, Fleshgrinder wrote: >> >> Maybe we could do some name brain storming? > > I would strongly recommend instead of that, sending fewer emails to > this list, with each email containing well thought through

Re: [PHP-DEV] [Bug #68319] unserialize() with modified class definition.

Looking into the number of unserialize() related "security" issues, I think we should fix all of them once and forever, introducing a validation pass. In case something in provided data is wrong (e.g. duplicated properties or array keys, unexpected types, invalid references, invalid property

[PHP-DEV] 7.1, 1 test failure with dtrace

With ./configure --disable-all make testTESTS=ext/reflection/ Tests failed:0 ( 0.0%) ( 0.0%) Tests passed: 326 ( 97.3%) (100.0%) With ./configure --disable-all --enable-dtrace Tests failed:1 ( 0.3%) ( 0.3%) Tests passed: 325 ( 97.0%) ( 99.7%) FAILED TEST SUMMARY

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-06-23

Results for project PHP master, build date 2016-06-23 06:29:38+03:00 commit: 782caa7 previous commit:5cf9e01 revision date: 2016-06-22 20:20:48+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB