Re: [PHP-DEV] Update coding standards wrt. C99?

[Xinchen Hui]

On Wed, May 6, 2020 at 6:20 PM Xinchen Hui  wrote:

>
> Hey:
>
> On Wed, May 6, 2020 at 3:32 PM Christoph M. Becker 
> wrote:
>
>> Hi all,
>>
>> since master requires (mostly) C99 compliant compilers anyway, I wonder
>> if we like to update our coding standards[1], to reflect:
>>
>>  * that we require (mostly) C99 compliant compilers (instead of ANSI-C
>> compliant compilers)
>>
>>  * that mixing of declarations and statements is fine
>>
>  IMO, mixing variables and codes are always not a good practice, strict is
> always means tidy..
>
>  mixing declarations and codes sometimes brings unexpected
> varaibles overriden and hard to debugging.
>
>  and, I don't think make variables declaration at top of a block is a hard
> thing to do.
>
And for me, and maybe others who have been work with c89 years,

mixed declaration and codes are guly. .

anyway, it's just my 2 cents.

thanks

>
> thanks
>
>>  * that C++ style comments are now allowed, or maybe that they are still
>> forbidden (in the latter case the stated reasons should be updated)
>>
>> We may also consider to drop the "Documentation and folding hooks"[2]
>> section; besides that it is already partially outdated (AIUI,
>> doc/genfuncsummary is superseeded by doc/docgen for a long time), I
>> don't think these folding markers encapsulating each individual function
>> are useful nowadays.
>>
>> Thoughts?
>>
>> [1] <https://github.com/php/php-src/blob/master/CODING_STANDARDS.md>
>> [2]
>> <
>> https://github.com/php/php-src/blob/master/CODING_STANDARDS.md#documentation-and-folding-hooks
>> >
>>
>> --
>> Christoph M. Becker
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Update coding standards wrt. C99?

[Xinchen Hui]

Hey:

On Wed, May 6, 2020 at 3:32 PM Christoph M. Becker 
wrote:

> Hi all,
>
> since master requires (mostly) C99 compliant compilers anyway, I wonder
> if we like to update our coding standards[1], to reflect:
>
>  * that we require (mostly) C99 compliant compilers (instead of ANSI-C
> compliant compilers)
>
>  * that mixing of declarations and statements is fine
>
 IMO, mixing variables and codes are always not a good practice, strict is
always means tidy..

 mixing declarations and codes sometimes brings unexpected
varaibles overriden and hard to debugging.

 and, I don't think make variables declaration at top of a block is a hard
thing to do.

thanks

>  * that C++ style comments are now allowed, or maybe that they are still
> forbidden (in the latter case the stated reasons should be updated)
>
> We may also consider to drop the "Documentation and folding hooks"[2]
> section; besides that it is already partially outdated (AIUI,
> doc/genfuncsummary is superseeded by doc/docgen for a long time), I
> don't think these folding markers encapsulating each individual function
> are useful nowadays.
>
> Thoughts?
>
> [1] <https://github.com/php/php-src/blob/master/CODING_STANDARDS.md>
> [2]
> <
> https://github.com/php/php-src/blob/master/CODING_STANDARDS.md#documentation-and-folding-hooks
> >
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Re: PHP 7.3 zif_handler changes

[Xinchen Hui]

Hey:
On Wed, Jun 27, 2018 at 9:44 PM Christoph M. Becker 
wrote:

> On 27.06.2018 at 08:47, Jan Ehrhardt wrote:
>
> > "Christoph M. Becker" in php.internals (Tue, 26 Jun 2018 13:15:32
> > +0200):
> >
> >> On 26.06.2018 at 08:42, Jan Ehrhardt wrote:
> >>
> >>>
> https://github.com/php/php-src/blob/php-7.3.0alpha2/UPGRADING.INTERNALS
> >>>
> >>> pecl_http:
> >>> |php_http_client_curl_user.c(190): error C2440: '=': cannot convert
> from 'void (__cdecl *)(zend_execute_data *,zval *)' to 'zif_handler'
> >
> > Mike fixed pecl_http:
> >
> https://github.com/m6w6/ext-http/commit/512f733beac73f37ba4acbcf730ebc6c6de849b6
> >
> > But we ran into another undocumented change:
> >
> https://github.com/m6w6/ext-http/commit/377d576a6e68def5708cf1ffcd3c233c4dddf356
> > `zval_ptr_dtor` had to be replaced by `zval_internal_dtor`.
> >
> >>> taint seems to have comparable errors. See
> >>>
> https://github.com/laruence/taint/commit/9debfe9682d22e172906cd2e7754a8380bf13453#commitcomment-29461798
> >
> > I fixed taint:
> >
> https://github.com/laruence/taint/commit/9debfe9682d22e172906cd2e7754a8380bf13453#commitcomment-29510740
> >
> >>> Can this be fixed and/or added to UPGRADING.INTERNALS?
> >>
> >> Apparently, zif_handler() has been changed to use the ZEND_FASTCALL
> >> calling convention[1] which results in this incompatibility.  Not sure
> >> if that should be reverted, or just documented in UPGRADING.INTERNALS.
> >
> > Any news from the RM's on this?
>
> Well, I'm looking forward to hear from the engine guys. :)
>
FAST_CALL should only affects win32.  and it can bring some improvement in
win32..

People should use zif_handler instead of define there own from now on, I
think documented it in UPGRADING is enough

thanks

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


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Weird PHP 7.2 bug

[Xinchen Hui]

Hey:

On Mon, Oct 30, 2017 at 3:55 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> Fixed. thanks. for catching.
>
Great

thanks

> The real problem - incorrect handling of "wrong index type.
>
> In this situation PHP should keep input array unchanged.
>
Inferring types "by usage" makes sense (for array)
>
> e.g. $a[$n]++ should change the type of array.
>
I

>
> Thanks. Dmitry.
>
>
> --
> *From:* Xinchen Hui <larue...@php.net>
> *Sent:* Monday, October 30, 2017 10:05:30 AM
> *To:* Derick Rethans
> *Cc:* Dmitry Stogov; Nikita Popov; PHP Developers Mailing List
> *Subject:* Re: [PHP-DEV] Weird PHP 7.2 bug
>
> Hey:
>
> On Mon, Oct 30, 2017 at 2:48 AM, Derick Rethans <der...@php.net> wrote:
>
>> Hi,
>>
>> running:
>> https://raw.githubusercontent.com/xdebug/xdebug/master/tests/bug01263.inc
>>
>> with:
>> $ php -n -dzend_extension=opcache.so -dopcache.enable_cli=1
>> tests/bug01263.inc
>>
>> Produces the following output with PHP 7.2 build at Oct 29 2017 18:49:58:
>>
>> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after
>> sccp):
>> var 10 (CV $data) has array value type but not key type
>> var 15 (CV $data) has array value type but not key type
>> var 21 (CV $data) has array value type but not key type
>>
>> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after
>> calls):
>> var 10 (CV $data) has array value type but not key type
>> var 15 (CV $data) has array value type but not key type
>> var 21 (CV $data) has array value type but not key type
>>
>> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after dce):
>> var 10 (CV $data) has array value type but not key type
>> var 15 (CV $data) has array value type but not key type
>> var 21 (CV $data) has array value type but not key type
>>
>> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after dfa):
>> var 10 (CV $data) has array value type but not key type
>> var 15 (CV $data) has array value type but not key type
>> var 21 (CV $data) has array value type but not key type
>>
> First, this won't bring any harm to execution,  this is becuase  we know 
> $uncoveredFiles
> are IS_UNDEF for sure(thus the foreach block actually won't be executed),
>
>
> then in typeinfo inference system, we will get $uncoveredFile with type
> info 0.
>
> then later while doing type inference for ZEND_FETCH_W 
> ($data[$uncoveredFile][$i]
> = ), since $unconveredFile has 0 type info, thus we won't get any key info
> of the array ($data),
>
> but in the current type inference system, FETCH_W's result will be used in
> ASSIGN_DIM , then the system think $data maybe an array of
> array(MAY_BE_ARRAY_OF_ARRAY).
>
> which result:  has array value type but not key type
>
> anyway, I think infer type infos by usage is wrong here, we should only
> trust def info, not use info...
>
> so, I propose fix this by: https://gist.github.com/laruence/
> 9990ce5f9f3b30dd98dbff4f59109232
>
> Dmitry, what do you think?
>
> thanks
>
>>
>>
>> cheers,
>> Derick
>>
>> --
>> https://derickrethans.nl | https://xdebug.org | https://dram.io
>> Like Xdebug? Consider a donation: https://xdebug.org/donate.php
>> twitter: @derickr and @xdebug
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Weird PHP 7.2 bug

[Xinchen Hui]

Hey:

On Mon, Oct 30, 2017 at 2:48 AM, Derick Rethans <der...@php.net> wrote:

> Hi,
>
> running:
> https://raw.githubusercontent.com/xdebug/xdebug/master/tests/bug01263.inc
>
> with:
> $ php -n -dzend_extension=opcache.so -dopcache.enable_cli=1
> tests/bug01263.inc
>
> Produces the following output with PHP 7.2 build at Oct 29 2017 18:49:58:
>
> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after sccp):
> var 10 (CV $data) has array value type but not key type
> var 15 (CV $data) has array value type but not key type
> var 21 (CV $data) has array value type but not key type
>
> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after
> calls):
> var 10 (CV $data) has array value type but not key type
> var 15 (CV $data) has array value type but not key type
> var 21 (CV $data) has array value type but not key type
>
> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after dce):
> var 10 (CV $data) has array value type but not key type
> var 15 (CV $data) has array value type but not key type
> var 21 (CV $data) has array value type but not key type
>
> In function PHP_CodeCoverage::addUncoveredFilesFromWhitelist (after dfa):
> var 10 (CV $data) has array value type but not key type
> var 15 (CV $data) has array value type but not key type
> var 21 (CV $data) has array value type but not key type
>
First, this won't bring any harm to execution,  this is becuase  we
know $uncoveredFiles
are IS_UNDEF for sure(thus the foreach block actually won't be executed),

then in typeinfo inference system, we will get $uncoveredFile with type
info 0.

then later while doing type inference for ZEND_FETCH_W
($data[$uncoveredFile][$i]
= ), since $unconveredFile has 0 type info, thus we won't get any key info
of the array ($data),

but in the current type inference system, FETCH_W's result will be used in
ASSIGN_DIM , then the system think $data maybe an array of
array(MAY_BE_ARRAY_OF_ARRAY).

which result:  has array value type but not key type

anyway, I think infer type infos by usage is wrong here, we should only
trust def info, not use info...

so, I propose fix this by:
https://gist.github.com/laruence/9990ce5f9f3b30dd98dbff4f59109232

Dmitry, what do you think?

thanks

>
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Request shutdown optimization

[Xinchen Hui]

Hey:

On Thu, Jun 22, 2017 at 3:29 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> hi,
>
>
> could you, please, review the PR https://github.com/php/php-src/pull/2591
>
>
> The main idea is not to free request-allocated zvals, because they are
> freed by Zend MM anyway.
>
> Also, shutdown_executor() code was simplified by calling destructors and
> closing resources, before freeing data.
>
>
> all tests are passed.
>
I don't see any problems,

(just one concern, fast_shutdown is only enable in non-debug mode, which
may cause troubles for debuging fast_shutdown problems, maybe we could
 change it to :

 fast_shutdown =
 #if ZEND_DEBUG
!report_memleaks &&
#endif
   is_zend_mm && !full_table_clean;
),

anyway, this feature is already exists in opcache for quite a long time, so
I think could commit it.


thanks

>
> Thanks. Dmitry.
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Regression between RC1 and RC2?

[Xinchen Hui]

Hey:

On Sun, Oct 9, 2016 at 2:06 AM, Anatol Belski <anatol@belski.net> wrote:

> Hi,
>
> > -Original Message-
> > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> > Shafik
> > Sent: Friday, October 7, 2016 10:05 PM
> > To: Nikita Popov <nikita@gmail.com>
> > Cc: Derick Rethans <der...@php.net>; PHP Developers Mailing List
> > <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Regression between RC1 and RC2?
> >
> > Yes, we should not mask the exception. The behavior in 7.0/7.1.0RC1 is
> much
> > better IMO.
> >
> > (As seen here: https://3v4l.org/EJpD4#v700)
> >
> > - Davey
> >
> > On Fri, Oct 7, 2016 at 12:52 PM, Nikita Popov <nikita@gmail.com>
> wrote:
> >
> > > On Fri, Oct 7, 2016 at 9:31 PM, Derick Rethans <der...@php.net> wrote:
> > >
> > > > Hi,
> > > >
> > > > I was looking at Xdebug for PHP 7.1, and I ran into the following
> > > > inconsistency:
> > > >
> > > > https://3v4l.org/tHteN
> > > >
> > > > I first thought that Xdebug was messing up, but it seems like it's
> > > > different behaviour in PHP itself. As I clearly return an array from
> > > > __debugInfo, I don't think the new result is the correct one.
> > > >
> > > > cheers,
> > > > Derick
> > > >
> > >
> > > This is due to https://github.com/php/php-src/commit/
> > > 2d8ab51576695630a7471ff829cc5ea10becdc0f, which landed in PHP-7.0 as
> > well.
> > > The problem is that __debugInfo currently is not able to handle
> > > exceptions gracefully. I think we should revert this change for now as
> > > it hides the fact that the underlying cause of the error is an
> exception.
> > >
> As far as I understand the bug #73067, it was about avoiding the fatal
> error, not about avoiding the exception. Please correct if I'm wrong. But
> given this, the fatal error still persists while the exception is removed.
> It looks like it's doing the exact reversed to what one would expect - no
> fatal error and the exception can be catched.
>
> I see that it's not yet released in 7.0, so I would prefer to revert this
> in the release, at least. Hui, Nikita, do you think it's possible to
> improve this for 7.0 in a follow up? I would revert in 7.0.12 and there'll
> be room to fix it in the dev branch till 7.0.13. Otherwise I'd suggest to
> revert to the previous behavior in 7.0+ and do a fix in an appropriate
> higher branch.
>
The real problem is:

we are expecting __debugInfo always returns array,  but it doesn't if
exception is threw.

so, if we keep the exception,  then we need inserts checks for
exception (no array) after every debugInfo is called, or, make a FATAL
error like the way I did

however,  I think latter is better,  but maybe we could improve the
fatal error message:

 " Fatal error,  __debugInfo must return an array, but an exception
with " msg" is threw"

thanks

>
> Thanks
>
> Anatol
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] JIT for PHP project

[Xinchen Hui]

Hey:

On Thu, Sep 1, 2016 at 7:57 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> Hi @internals,
>
> I'm glad to say that we have started a new JIT for PHP project and hope to
> deliver some useful results for the next PHP version (probably 8.0).
> We are very early in the process and for now there isn't any real
> performance improvement yet.  So far we spent just 2 weeks mainly working
> on JIT infrastructure for x86/x86_64 Linux (machine code generation,
> disassembling, debugging, profiling, etc), and we especially made the JIT
> code-generator as minimal and simple as possible. The current state, is
> going to be used as a starting point for research of different JIT
> approaches and their usability for PHP.
>
> The code is available at: https://github.com/zendtech/
> php-src/tree/jit-dynasm/ext/opcache/jit
>
> The sources may be built and tested as regular PHP (no any special
> external dependencies required).
> JIT itself is implemented as a part of Opcache.
> You may try it in action:
>
> sapi/cli/php -d opcache.jit_buffer_size=32M Zend/bench.php
> sapi/cli/php -d opcache.jit_buffer_size=32M -d opcache.jit_debug=1
> Zend/bench.php 2>&1 | less
>
> As I mentioned we didn't try to achieve any real performance improvement
> yet, although we do currently see 20% speedup on bench.php, but a bit of a
> slowdown on real-life apps.
>
Actually,  if you are lucky like me, you may see like 5% improvement on
wordpress. :)

thanks

>
> Wish us luck :)
>
> Thanks. Dmitry.
>
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] More packed hash optimizations in array.c

[Xinchen Hui]

Hey:

On Wed, Aug 3, 2016 at 10:48 PM, Benjamin Coutu <ben.co...@zeyos.com> wrote:

> Hello Xinchen,
>
> Thanks for changing array_pad and array_rand accordingly, that's very good.
>
> I noticed a small improvement we could make to array_slice for the packed
> case:
>
> We can change line 3003:
> if ((Z_ARRVAL_P(input)->u.flags & HASH_FLAG_PACKED) && !preserve_keys)
> =>
> if ((Z_ARRVAL_P(input)->u.flags & HASH_FLAG_PACKED) && (!preserve_keys ||
> offset == 0))
>
> So whenever the input array is packed, we can of course safely use a
> packed array for the output array when preserve_keys is false, but also
> when preserve_keys is true and if (only if) the offset is zero, because
> offset=0 on a packed array will yield the same result no matter whether
> preserved_keys is true or false.
>
packed array doesn't means alwasy start with index 0,

like:

$array = array(1 => 1, 2, 3, 4, 5, 6);

this is also a packed array

so,  we can not do such opt only if offset == 0

thanks

>
> Ben
>
>
> == Original ==
> From: Xinchen Hui <xinche...@zend.com>
> To: Benjamin Coutu <ben.co...@zeyos.com>
> Date: Tue, 02 Aug 2016 08:32:14 +0200
> Subject: Re: [PHP-DEV] More packed hash optimizations in array.c
>
> Hey:
>
> On Tue, Aug 2, 2016 at 2:21 PM, Benjamin Coutu <ben.co...@zeyos.com>
> wrote:
>
>> Hello Xinchen,
>>
>> Thanks for implementing.
>> Unfortunatly we just broke array_column by mistake. My description might
>> not have been clear enough.
>>
>> We can only create a packed array when $index_key=null AND if the input
>> array was already a packed array, because array_column must preserve
>> keys if index_key=null.
>>
>  Hmm, it should not, I reviewed the origin implementation:
>
>  if (zkey) {
> zkeyval = array_column_fetch_prop(data, zkey, );
> }
>
> Z_TRY_ADDREF_P(zcolval);
> if (zkeyval && Z_TYPE_P(zkeyval) == IS_STRING) {
> zend_symtable_update(Z_ARRVAL_P(return_value),
> Z_STR_P(zkeyval), zcolval);
> } else if (zkeyval && Z_TYPE_P(zkeyval) == IS_LONG) {
> add_index_zval(return_value, Z_LVAL_P(zkeyval), zcolval);
> } else if (zkeyval && Z_TYPE_P(zkeyval) == IS_OBJECT) {
> zend_string *key = zval_get_string(zkeyval);
> zend_symtable_update(Z_ARRVAL_P(return_value), key, zcolval);
> zend_string_release(key);
> } else {
>     add_next_index_zval(return_value, zcolval);
> }
>
> if zkey is NULL(index_key),  then only add_next_index_zval is executed.
>
> do you have any reproduce script to show the broken?
>
> thanks
>
>>
>> Cheers,
>>
>> Benjamin
>>
>> == Original ==
>> From: Xinchen Hui <xinche...@zend.com>
>> To: Benjamin Coutu <ben.co...@zeyos.com>
>> Date: Tue, 02 Aug 2016 06:45:18 +0200
>> Subject: Re: [PHP-DEV] More packed hash optimizations in array.c
>>
>>
>> Hey
>>
>> On Thu, Jul 28, 2016 at 4:59 PM, Benjamin Coutu <ben.co...@zeyos.com>
>> wrote:
>>
>>> Hello Xinchen,
>>>
>>> I have noticed two more cases where we could easily use packed arrays.
>>>
>>> 1. array_merge($packed1, $packed2, ...):
>>>
>>> In the quite common case where all arguments are packed arrays, the
>>> resulting array can also be a packed array (as per documentation: "if the
>>> input arrays [...] contain numeric keys, the later value will not overwrite
>>> the original value, but will be appended"), thereby ensuring that packed
>>> arrays stay packed when appended to one another.
>>> In general we should try to preserve the packed characteristics wherever
>>> possible.
>>>
>> I will need do some benchmark, as it is already very simple
>> implementation now.
>>
>>>
>>> 2. array_column($input, $column_key, $index_key=null):
>>>
>>> For the common case when $index_key=null, we can just create a packed
>>> array.
>>> Also (not related to packing), we could pre-initialize the return_value
>>> array size with array_init_size() if, and only if, $column_key=null.
>>>
>> this one is committed here:
>> https://github.com/php/php-src/commit/fea2042a47dbda7210306c881a9f0a82b8503a45
>>
>> thanks
>>
>>>
>>> Please let me know your thoughts.
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>> --
>>>
>>> Bejamin Coutu
>>> ben.co...@zeyos.com
>>>
>>> ZeyOS, Inc.
>>> http://www.zeyos.com
>>>
>>>
>>
>>
>> --
>> Xinchen Hui
>> @Laruence
>> http://www.laruence.com/
>>
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] More packed hash optimizations in array.c

[Xinchen Hui]

Hey:

On Tue, Aug 2, 2016 at 2:21 PM, Benjamin Coutu <ben.co...@zeyos.com> wrote:

> Hello Xinchen,
>
> Thanks for implementing.
> Unfortunatly we just broke array_column by mistake. My description might
> not have been clear enough.
>
> We can only create a packed array when $index_key=null AND if the input
> array was already a packed array, because array_column must preserve keys
> if index_key=null.
>
 Hmm, it should not, I reviewed the origin implementation:

 if (zkey) {
zkeyval = array_column_fetch_prop(data, zkey, );
}

Z_TRY_ADDREF_P(zcolval);
if (zkeyval && Z_TYPE_P(zkeyval) == IS_STRING) {
zend_symtable_update(Z_ARRVAL_P(return_value),
Z_STR_P(zkeyval), zcolval);
} else if (zkeyval && Z_TYPE_P(zkeyval) == IS_LONG) {
add_index_zval(return_value, Z_LVAL_P(zkeyval), zcolval);
} else if (zkeyval && Z_TYPE_P(zkeyval) == IS_OBJECT) {
zend_string *key = zval_get_string(zkeyval);
zend_symtable_update(Z_ARRVAL_P(return_value), key, zcolval);
zend_string_release(key);
} else {
add_next_index_zval(return_value, zcolval);
}

if zkey is NULL(index_key),  then only add_next_index_zval is executed.

do you have any reproduce script to show the broken?

thanks

>
> Cheers,
>
> Benjamin
>
> == Original ==
> From: Xinchen Hui <xinche...@zend.com>
> To: Benjamin Coutu <ben.co...@zeyos.com>
> Date: Tue, 02 Aug 2016 06:45:18 +0200
> Subject: Re: [PHP-DEV] More packed hash optimizations in array.c
>
>
> Hey
>
> On Thu, Jul 28, 2016 at 4:59 PM, Benjamin Coutu <ben.co...@zeyos.com>
> wrote:
>
>> Hello Xinchen,
>>
>> I have noticed two more cases where we could easily use packed arrays.
>>
>> 1. array_merge($packed1, $packed2, ...):
>>
>> In the quite common case where all arguments are packed arrays, the
>> resulting array can also be a packed array (as per documentation: "if the
>> input arrays [...] contain numeric keys, the later value will not overwrite
>> the original value, but will be appended"), thereby ensuring that packed
>> arrays stay packed when appended to one another.
>> In general we should try to preserve the packed characteristics wherever
>> possible.
>>
> I will need do some benchmark, as it is already very simple implementation
> now.
>
>>
>> 2. array_column($input, $column_key, $index_key=null):
>>
>> For the common case when $index_key=null, we can just create a packed
>> array.
>> Also (not related to packing), we could pre-initialize the return_value
>> array size with array_init_size() if, and only if, $column_key=null.
>>
> this one is committed here:
> https://github.com/php/php-src/commit/fea2042a47dbda7210306c881a9f0a82b8503a45
>
> thanks
>
>>
>> Please let me know your thoughts.
>>
>> Thanks,
>>
>> Ben
>>
>> --
>>
>> Bejamin Coutu
>> ben.co...@zeyos.com
>>
>> ZeyOS, Inc.
>> http://www.zeyos.com
>>
>>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] More packed hash optimizations in array.c

[Xinchen Hui]

Hey

On Thu, Jul 28, 2016 at 4:59 PM, Benjamin Coutu <ben.co...@zeyos.com> wrote:

> Hello Xinchen,
>
> I have noticed two more cases where we could easily use packed arrays.
>
> 1. array_merge($packed1, $packed2, ...):
>
> In the quite common case where all arguments are packed arrays, the
> resulting array can also be a packed array (as per documentation: "if the
> input arrays [...] contain numeric keys, the later value will not overwrite
> the original value, but will be appended"), thereby ensuring that packed
> arrays stay packed when appended to one another.
> In general we should try to preserve the packed characteristics wherever
> possible.
>
I will need do some benchmark, as it is already very simple implementation
now.

>
> 2. array_column($input, $column_key, $index_key=null):
>
> For the common case when $index_key=null, we can just create a packed
> array.
> Also (not related to packing), we could pre-initialize the return_value
> array size with array_init_size() if, and only if, $column_key=null.
>
this one is committed here:
https://github.com/php/php-src/commit/fea2042a47dbda7210306c881a9f0a82b8503a45

thanks

>
> Please let me know your thoughts.
>
> Thanks,
>
> Ben
>
> --
>
> Bejamin Coutu
> ben.co...@zeyos.com
>
> ZeyOS, Inc.
> http://www.zeyos.com
>
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Optimizing array_reverse for packed hash tables (when preserve_keys=false)

[Xinchen Hui]

Hey:

On Wed, Jul 27, 2016 at 10:42 PM, Benjamin Coutu <ben.co...@zeyos.com>
wrote:

> Hello Xinchen,
>
> Analogue to the array_slice implementation, the array_reverse function
> could also be optimized for packed hash tables when preserve_keys is false
> (most common).
> The following patch should do just that:
>
> if (!preserve_keys && (Z_ARRVAL_P(input)->u.flags & HASH_FLAG_PACKED)) {
> zend_hash_real_init(Z_ARRVAL_P(return_value), 1);
>
> ZEND_HASH_FILL_PACKED(Z_ARRVAL_P(return_value)) {
> ZEND_HASH_REVERSE_FOREACH_VAL(Z_ARRVAL_P(input), entry) {
> ZEND_HASH_FILL_ADD(entry);
> zval_add_ref(entry);
> } ZEND_HASH_FOREACH_END();
> } ZEND_HASH_FILL_END();
> }
>
> Please let me know your thoughts.
>
I think it's a good idea,

one suggestion is  you should check HASH_FLAG_PACKED first, as
!perserve_keys is most common.

and maybe you should use Z_TRY_ADDREF instead of zval_add_ref, check
REFCOUNTED in place, to save one function call if it's not TYPE_REFCOUNTED.

btw, do you want to make a PR yourself, or let me to commit your idea?

thanks

>
> Thanks,
>
> Ben
>
> --
>
> Bejamin Coutu
> ben.co...@zeyos.com
>
> ZeyOS, Inc.
> http://www.zeyos.com
>
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[Xinchen Hui]

Hey:

On Thu, Jun 23, 2016 at 5:04 PM, Benjamin Coutu <ben.co...@zeyos.com> 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.
>
> That represents a clear inconsistency, because all other array sorting
> functions utilize the advanced implementation of quicksort (through
> zend_hash_sort) that was derived from LLVM's libc++ implementation of
> std::sort (https://marc.info/?l=php-internals=142047779209352).
>
> Not only is zend_qsort less efficient, but moreover, because it doesn't
> rely on the insertion sort fallback for small array chunks that zend_sort
> provides (which yields a more stable sorting order), the result might in
> effect actually differ from that of all the other array sorting functions.
>
> IMHO this inconsistency can be considered a bug.
>
> Also, array_multisort is the only remnant in PHP core that still uses
> zend_qsort (https://github.com/php/php-src/search?q=zend_qsort). If we
> would eliminate that inconsistency, we could probably dispense with the
> then obsolete zend_qsort all together.
>
> Please let me know your thoughts.
>
Thanks for the notice, it is long time,  I don't remember why I didn't
change that,  but it does looks like a oversight to me now.

I will change it to use zend_sort in 7.1 ,  however, we can not remove
zend_qsort, because its a ZEND_API , some third extensions may use it.

thanks


> Thanks,
>
> Ben
>
> --
>
> Bejamin Coutu
> ben.co...@zeyos.com
>
> ZeyOS, Inc.
> http://www.zeyos.com
>
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Enable Zend Signals by Default

[Xinchen Hui]

Hey:

On Tue, Jun 21, 2016 at 9:02 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:

> On Mon, Jun 20, 2016 at 1:25 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
> So, I propose to switch zend-signals on, and revert back if it makes
> problems to 7.1 release process.
> Any objections?
>
>
> No objections here. I have been hitting annoying segfaults in 7.0 that
> will likely be helped by this.
>
No objections here neither, I already tried enable it in 7.0 :)

thanks


>
> -Rasmus
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Xinchen Hui]

Hey:

On Sat, Jun 11, 2016 at 4:06 AM, Dmitry Stogov <dmi...@zend.com> wrote:

> Hi internals,
>
>
> Please review: https://wiki.php.net/rfc/constant_redefinition


we could also change the

#define DEFAULT_OPTIMIZATION_LEVEL  "0x7FFFBFFF" (introduced in
https://github.com/php/php-src/commit/40702799b5f08b093477098881b6e0cfcb3ea411
)

to  -1

I think it's better also include this into the patch?

thanks

>
>
> Thanks. Dmitry.
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

[Xinchen Hui]

Hey:



On Tue, May 24, 2016 at 4:24 AM, Dmitry Stogov <dmi...@zend.com> wrote:

> Hi internals,
>
>
> Please review the RFC.
>
> It proposes to fix all known inconsistencies related to handling of
> special $this variable.
>
in section static this,   actually, the codes doesn't work in 7.0 neither.

it will result in fatal error:   PHP Fatal error:  Cannot re-assign $this

thanks

>
> https://wiki.php.net/rfc/this_var
>
>
> Thanks. Dmitry.
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] reused hash tables in large data structures in PHP7

[Xinchen Hui]

Hey:

On Tue, May 17, 2016 at 6:00 AM, Adam Baratz <adam.bar...@gmail.com> wrote:

> Hi,
>
> I've encountered a hard-to-consistently-reproduce issue with HashTable
> zvals. I have code that will generate big nested \stdClass structures for
> JSON encoding. It does so using classes that have methods that generate
> those fields. For example, you could have a class like this:
>
> class Block {
>   public function css_classes() {
> return ['x', 'y', 'z'];
>   }
> }
>
> Other code would translate it into a value that would var_dump() as this:
>
> object(stdClass)#1 (1) {
>   ["css_classes"]=>
>   array(3) {
> [0]=>
> string(1) "x"
> [1]=>
> string(1) "y"
> [2]=>
> string(1) "z"
>   }
> }
>
> The template data could include multiple instances of Block. As in, a
> \stdClass could be generated with multiple copies of that array content.
> That data could get sent to json_encode(), which
> uses ZEND_HASH_APPLY_PROTECTION/etc. to avoid recursion. I've seen
> situations where that array of strings triggers that recursion check. But
>
the array might be stored in shared memory(immutable array), in this case,
you should not edit the apply count ,

you should check it,  like what json does:

https://github.com/php/php-src/blob/master/ext/json/json_encoder.c#L156


thanks

it's not always, and a php-fpm restart can make it go away.
>
> Can anyone think of why this might happen?
>
> Thanks,
> Adam
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

[Xinchen Hui]

Hey:



On Mon, Apr 25, 2016 at 10:09 PM, S.A.N <ua.san.a...@gmail.com> wrote:

> In userland  lacks the ability to store data in the shared memory
> modules, do not use pecl modules, it would be very nice to have a
> function:
>
> opcache_get($key);
> opcache_set($key, $value);
>
> Is planned in PHP 7.1?
>
you could try https://github.com/laruence/yac

it's a  "A fast shared memory user data cache for PHP "

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Object getter method optimization

[Xinchen Hui]

Hey:

On Fri, Apr 1, 2016 at 4:35 PM, Lin Yo-An <cornelius.h...@gmail.com> wrote:

> Hi Dmitry, Nikita, Andrea
>
>
> My implementation now is able to get the property offset and fetch object
> property directly without invoking zend_std_read_property and pushing new
> call frame onto the stack.
>
> The current behavior:
>
> 1. In compile-time, the pass_two() function now marks the getter functions
> in op_array.accessor.type
>
> 2. When Zend Engine first time attempt to read the property, it saves the
> property offset in the accessor field and mark the method as a "getter".
>
I am not sure if I understand you correctly, but.. have you consider this
case?

a;
} else {
return $this->b;
}
}
}


$a = new A();
echo $a->nomeaning;
echo $a->nomeaning;
?>

thanks

>
> 3. When Zend Engine second time invoke the getter method, it checks the
> accessor field and try to read the property value directly instead a
> "method call"
>
>
>
> The implementation did some change:
>
> 1. Added accessor struct to op_array to save "accessor" related
> information (getter or setter, property offset)
>
> 2. Added two statement in zend_std_read_property to save property offset.
>
> 3. Added op code check in zend_compile (The pass_two() function) to mark a
> function is a getter)
>
>
> But now I encountered a problem, I can't store the result value in
> INIT_METHOD_CALL op, the result var is only available in DO_FCALL_*
>
>
>
> I have an idea for solving this, but I'm not sure if it's good or not:
>
>
> If DO_FCALL_* will always follow a INIT_METHOD_CALL, then I think we can
> store result var from the next op (DO_FCALL) and skip DO_FCALL directly.
>
>
> Would be great if I can have your advices and suggestion. :-)
>
>
> Thanks, Yo-An Lin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 22, 2016 at 4:45 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>> Hi Yo-An Lin,
>>
>>
>> This "run-time inlining" approach may work.
>>
>>
>> PHP compiler (or optimizer) may mark functions and methods suitable for
>> "run-time" inlining (e.g. methods without arguments and FETCH_OBJ_R UNUSED,
>> CONST -> TMP; RETURN TMP).
>>
>> Then INIT_METHOD_CALL may check this flag and execute "optimized code
>> sequence" instead of pushing stack frame and real call.
>>
>>
>> However, I'm not sure what kind of performance impact this may make,
>> because we will have to make additional check on each INIT_METHOD_CALL
>> execution.
>>
>>
>> Thanks. Dmitry.
>>
>>
>> --
>> *From:* Lin Yo-An <cornelius.h...@gmail.com>
>> *Sent:* Saturday, March 19, 2016 10:08
>> *To:* Dmitry Stogov
>> *Cc:* internals; Xinchen Hui
>> *Subject:* Re: [PHP-DEV] Object getter method optimization
>>
>> Hi Dmitry,
>>
>>
>> Thanks for your reply! You're correct. let me try to explain your points:
>>
>> If I have a main.php and worker.php
>>
>> And I defined work($worker) { $status = $worker->getStatus(); } inside
>> main.php
>>
>> when main.php is compiled, we don't know what the class entry of $worker
>> is. What we only know is invoking a method "getStatus" on $worker CV unless
>> we know we have to compile worker.php before main.php and add a type hint
>> on $worker.
>>
>> Is it correct?
>>
>>
>> Since the original approach doesn't work, here comes another new idea:
>>
>> When executing method call on an object, if we found the method body are
>> just 2 op codes (FETCH_OBJ_R and RETURN), we then denote the method is a
>> "getter method"
>>
>> And the next time, when we execute the same method, we found the "getter
>> method" flag, we simply execute FETCH_OBJ_R on that object and return the
>> value to avoid extra op code execution time.
>>
>> Do you think if this could work?
>>
>>
>>
>>
>> Best Regards and Thanks for your work on PHP VM
>> Yo-An Lin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 18, 2016 at 3:36 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>>
>>> Hi Yo-An Lin,
>>>
>>> Unfortunately, this approach won't work.
>>> 

Re: [PHP-DEV] Change in internal call_user_function() API.

[Xinchen Hui]

Hey:

On Thu, Feb 25, 2016 at 11:16 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> Hi,
>
>
> PHP-7.0 internal call_user_function() API doesn't support function calls
> with preinitialised symbol tables.
>
> This just can't work in general , because values of arguments might be
> already initialized in CV as well as in symbol table.
>
>
> I propose to remove the corresponding internal API in master:
>
> 1) remove last argument of call_user_function_ex()
>
> 2) remove zend_call_info.symbol_table field
>
 I think it's okey,  (I assume this is for 7.1, right?)

 the value caller want to pass in should goes via arguments, which is a
more reasonable way.

thanks

>
>
> https://gist.github.com/dstogov/5550827aa695ff8cb803
>
>
> The tricky way was used in phpdbg only, but that code doesn't work, and
> should be fixed anyway.
>
>
> Thanks. Dmitry.
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Xinchen Hui]

Hey:

On Wed, Jan 20, 2016 at 7:05 PM, Michael Wallner <m...@php.net> wrote:

> On 08/12/15 10:56, Dmitry Stogov wrote:
> > Hi Sean,
> >
> > The PR has been merged into master.
> > Please update the RFC accordingly.
> > Thanks to Nikita and Xinchen for code review and suggestions.
> >
>
>
> This patch seems to cause problems for me with registering constants on
> internal interfaces; see bug #71413 https://bugs.php.net/71413

this should be fixed in :
https://github.com/php/php-src/commit/62c1c11ad34103729988df9edea343337a900ba9

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Line numbers for "finally"

[Xinchen Hui]

Hey:


On Sat, Jan 2, 2016 at 7:59 PM, Derick Rethans <der...@php.net> wrote:

> On Thu, 31 Dec 2015, Nikita Popov wrote:
>
> > On Thu, Dec 31, 2015 at 1:09 AM, Derick Rethans <der...@php.net> wrote:
> >
> > > On Thu, 31 Dec 2015, Nikita Popov wrote:
> > >
> > > > For PHP 7 only: FAST_CALL always jumps to op1. op2 is not a jmp
> > > > addr, it's a try_catch_array offset. For FAST_RET there are no
> > > > jump addresses encoded in the opline. It will either jump back to
> > > > one past the invoking FAST_CALL (of which there may be multiple),
> > > > or (if finally is executed due to an uncaught exception) it will
> > > > jump back to the next applicable catch or finally or leave the
> > > > function.
> > >
> > > Hmm, that's more complicated than I thought. How would I fix that
> > > code? (PR welcome :D )
> >
> > I don't know what you need this for, but maybe you can use the same
> > "good enough" approximation we use for our internal control flow
> > analysis, namely simply say that FAST_CALL either jumps to op1 or to
> > the next instruction, while FAST_RET is treated as a terminator
> > instruction (like RETURN). This does not accurately model control
> > flow, but it may be sufficient for your purposes.
>
> I need to analyse every possible branch, and path through the code in
> order to do dead code analysis (for which I think your simplified
> option works), but also for path coverage, for which I don't think your
> algorithm works. Xinchen alluded on IRC:
>
> 15:21 <@laruence> Derick, it used for calling "finally block"
> 15:22 <@laruence> it has the entry opline of finally block  as opline->op1
> 15:22 <@laruence> and in the end of finally block ,there always be a
>   ZEND_FAST_RET opline, which will return to proper address
>   after finally block codes is executed
>
> To me that indicates that the FAST_RET can jump back to any location
> where FAST_CALL was *called* from (+1)?
>
> In any case, I think my current code does what you describe, except for
> FAST_RET, as that does not act like a RETURN - is there any reason why
> my approach wouldn't work?
>
> Some more observations and questions:
>
> FAST_CALL:
> *jmp1 = XDEBUG_ZNODE_JMP_LINE(opcode.op1, position, base_address);
>
> - But what do do for *jmp2 - if extended_value is set?

if extended_value is set(FROM_FINALLY) that means this finally block is
inside another finally block

I am not sure what *jmp2 means here? ZEND_FAST_CALL always jmp to one
place. but  in case FROM_FINALLY it has outer FAST_CALL's opline in op2 .


> - I can't come up with PHP code that sets extended_value though. Can you?
>
try  {
} finally {
   try  {
   } finally /* this fast_call will set with FROM_FINALLY*/
   {}
}

>
> FAST_RET:
> *jmp1 = position + 1;
>
> - But you indicate that that really should be *jmp1 = XDEBUG_JMP_EXIT?
>
> - Or, it should jump back to something else?
> - But how do I know to which possible opline(s) it is going to jump back
> to?

- Is there a list of these somewhere?

I am afarid there is not, let me try to summary it(I will try to make it
clean, but mine poor english :<):

ZEND_FAST_CALL opcode is used for set a proper return address for
ZEND_FAST_RET.

there are two ways can entry a finally block, ZEND_FAST_CALL and
ZEND_HANDLE_EXCEPTION:

1) ZEND_FAST_CALL:  it set the return address to it's self (it will always
follow by a JMP, which will JMP to end of finall block).
2) ZEND_HANDLE_EXCEPTION, if there is catch block then jmp to it(in the end
of the catch block there will be a JMP to finally block), if no catch block
is matched and there is a finally block, then set fast_call_var->u2.lineno
== -1, and stash the EG(exception) into Z_OBJ_P(fast_call_var), then jmp to
the finally block.

for FAST_RET:
   in fast_ret, if fast_call_var->u2.lineno != -1, then it means a jmp
address, simply jmp to it.

   if  fast_call->u2.lineno == -1, then there must be a un-handle
exception(stored in Z_OBJ_P(fast_call_var)),  so:

   if RET_TO_FINALLY(see blow), means there is another finally block needs
to be run, jmp to the  ZEND_FAST_CALL opline of that finally block, in
which opline handle, if opline->extended_value
== ZEND_FAST_CALL_FROM_FINALLY(see below) and obviously current
Z_OBJ_P(fast_call_var) is set, then goes into the finally block behavior
like the way ZEND_HANDLE_EXCEPTION did, which is set the
fast_call->u2.lineno to -1, and jmp into the finally block.

  otherwise, restore the exception,  then goes like a new  exception is
throw(jmp to a CATCH block or leave current function which will result
ZEND_HANDLE_EXCEPTION again).



- I can't come up with PHP code that sets extended_value here either.
>
try  {
   try {
   } finally {

   } /* this fast_ret will set to RET_TO_CATCH */

}  catch () {
}

try  {
   try {
   } finally {

   } /* this fast_ret will set to RET_TO_FINALLY */

}  finally {
}

thanks

>   Can you?


thanks

>
> cheers,
> Derick
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] What's up with gcov.php.net?

[Xinchen Hui]

Hey:


On Thu, Dec 31, 2015 at 5:19 PM, Michael Wallner <m...@php.net> wrote:

>
> > On 30 12 2015, at 22:34, Andrea Faulds <a...@ajf.me> wrote:
> >
> > Hi everyone,
> >
> > If any of you have looked at http://gcov.php.net any time in the last
> three years, you'll probably have noticed an alarming and inexplicably high
> number of test failures. And if you've looked at Travis, you'll have seen
> much more reasonable numbers (i.e. usually zero).
>
> A guess might be, that many of the tests run on gcov are disabled on
> travis.
>
> >
> > So, I'd like to ask, why does gcov.php.net always show such high
> numbers, and apparently has things that are fixed show up as broken, and
> secondly, since we use Travis for continuous integration these days, why is
> the box even still running?
>
> gcov is about coverage too, so…
>
and also valgrind, which is quite useful, since it takes too long to run in
laptop.

thanks

>
> Anyway, you’ve probably got to talk to Nuno; IIRC he was/is managing the
> gcov box.
>
> Cheers,
> Mike
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] opcache.file_cache_only = 1 disables Opcode Caching

[Xinchen Hui]

Hey:

On Tue, Dec 29, 2015 at 3:31 PM, Tom Sommer <m...@tomsommer.dk> wrote:

> Awesome feature with opcache.file_cache_only, really exciting :)
>
> A couple of things:
>
> 1) It's not documented in the manual
>
yes, it's an experimental feature now

>
> 2) When you set opcache.file_cache_only = 1, the "Opcode Caching"
> information in phpinfo() disappears.
> "Opcode Caching" and "Optimization" is shown as "Disabled". Is this
> intended?
>

fixed in :
https://github.com/php/php-src/commit/3f07a256f75a55eaf7e7bfed681f8dfb4b901e55

now it will print:

Zend OPcache

Opcode Caching => Up and Running
Optimization => Enabled
SHM Cache => Disabled
File Cache => Enabled
Startup => OK

thanks


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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] PHP7 Zend Heap validation

[Xinchen Hui]

Hey:

On Sat, Dec 26, 2015 at 1:01 PM, <akin.o...@thomsonreuters.com> wrote:

> Hi everyone,
>
> I am working on porting a pre-PHP7 database driver extension to PHP7 for
> Windows platforms.
> ( I am using PHP 7.0.1 master branch code and targeting non-ZTS 32 bit
> PHP7 on Windows Server 2012 R2 )
> And currently as I did mechanical bits of porting ( compilation issues,
> getting functionality working
> mostly followed https://wiki.php.net/phpng-upgrading ) , my extension is
> only crash-free if I run it with
> USE_ZEND_ALLOC=0.
>
> However with USE_ZEND_ALLOC=1 , I am getting crashes inside
> zend_mm_alloc_small. As checked with Windbg :
> ...
> if (EXPECTED(heap->free_slot[bin_num] != NULL) )
> {
> zend_mm_free_slot *p =
> heap->free_slot[bin_num];
> if ( p->next_free_slot != NULL )


> Above , p->next_free_slot is not readable. I believe , currently I am
> getting the Zend heap corrupt.
> I am running a test script and  I tried disabling many things ,and
> enabling one by one to have an idea, from the looks of it , I am getting
> this issue
> around a zend_register_resource call but to me that one looks legitimate
> so I can`t easily pinpoint where the Zend heap gets corrupt.
>
> Diffrently from pre-PHP7 where we had full_mem_check , now I can see
> ZEND_MM_CHECK is placed in memory manager functions.
>
> I wanted to ask if there is any chance if we can have a heap integrity
> checker function , or what would you advise
> regarding to track down the places in our code corrupting the Zend MM ?
>
I am not familar with windows, but if it can be run in linux

you could try with "USE_ZEND_ALLOC=0 valgrind --tool=memcheck "

not sure if there is similar tool on windows


thanks

>
> Regards,
> Akin Ocal
>
> 
>
> This e-mail is for the sole use of the intended recipient and contains
> information that may be privileged and/or confidential. If you are not an
> intended recipient, please notify the sender by return e-mail and delete
> this e-mail and any attachments. Certain required legal entity disclosures
> can be accessed on our website.<
> http://site.thomsonreuters.com/site/disclosures/>
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] ext/interbase maintanance

[Xinchen Hui]

Hey:


On Tue, Dec 22, 2015 at 7:41 PM, Xinchen Hui <larue...@gmail.com> wrote:

> Hey：
>
> Sent from my iPhone
>
> > On Dec 22, 2015, at 18:23, Lester Caine <les...@lsces.co.uk> wrote:
> >
> > On 22/12/15 08:43, Xinchen Hui wrote:
> >>> Here is a working patch of mine:
> >> https://gist.github.com/laruence/f3af903012902818d7da
> >>
> >> if you are going to work on this, please base on this one.
> >>
> >> since I still don't have setup a evn to test it... so there might be
> some
> >> problems
> >>
> >> thanks
> >
> > Xinchen ... working test setup should be easy, but I'm more than happy
> > to run tests, my problem is the core code has changed so drastically
> > since I ACTUALLY did bug fixes at that level that I don't understand the
> > current methods :(
> >
> > I can understand this new patch but I still need to back-pedal the old
> > one. The only bit I'm not quite following is the switching between
> > 'NULL' and '0' as I'm not sure why you are switching to '0' for some
> > handles that are currently 'NULL' and then defaulting others which were
> > '0' to 'NULL'  but I think it's that we are now passing a pointer rather
> > than a handle?
> >
> complier wanrning about handle are int
>
> Anyway, this patch is not finish,  I hope I can finish this whole work in
> this week
>
> Will update here when it is done
>
Consider it done.

No compiler warnings anymore(expect the char* and ISC_UCHAR* mismatch)

However, there are some test fails, which I am not quite sure about.

Anyone who is faimilar with firebird, please help

https://gist.github.com/laruence/f3af903012902818d7da

thanks

>
> Thanks
> > I need to re-sync my repository with git.php.net then at least I can
> > track and roll back changes ... I'll get back to this later
> >
> > --
> > Lester Caine - G8HFL
> > -
> > Contact - http://lsces.co.uk/wiki/?page=contact
> > L.S.Caine Electronic Services - http://lsces.co.uk
> > EnquirySolve - http://enquirysolve.com/
> > Model Engineers Digital Workshop - http://medw.co.uk
> > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] ext/interbase maintanance

[Xinchen Hui]

Hey:

On Mon, Dec 21, 2015 at 10:30 PM, Anatol Belski <anatol@belski.net>
wrote:

> Hi Marius Adrian,
>
> It's a ping as you was expressing the intention to maintain ext/interbase
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extinterbase . How
> it currently looks like, ext/interbase is still broken and is not
> completely
> ported to PHP7. Fe there's currently this bug ticket
> https://bugs.php.net/bug.php?id=71175 and there are quite bad compilation
> warnings (only a part linked here
> https://gist.github.com/weltling/b352eace02ef5e1c4797 ). As Firebird is
> used
> less often, it's not the case for a quick fix for everyone, as the test
> environment is missing. Could you please go for the ext/interbase now? For
> the particular bug and in general, it was only taken off from voting
> because
> you've expressed the intention to maintain it
>
> http://grokbase.com/p/php/php-internals/151mxve1t5/php-dev-rfc-discussion-re
> moval-of-dead-sapis-and-extensions .
>
> Here is a working patch of mine:
https://gist.github.com/laruence/f3af903012902818d7da

if you are going to work on this, please base on this one.

since I still don't have setup a evn to test it... so there might be some
problems

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] ext/interbase maintanance

[Xinchen Hui]

Hey：

Sent from my iPhone

> On Dec 22, 2015, at 18:23, Lester Caine <les...@lsces.co.uk> wrote:
> 
> On 22/12/15 08:43, Xinchen Hui wrote:
>>> Here is a working patch of mine:
>> https://gist.github.com/laruence/f3af903012902818d7da
>> 
>> if you are going to work on this, please base on this one.
>> 
>> since I still don't have setup a evn to test it... so there might be some
>> problems
>> 
>> thanks
> 
> Xinchen ... working test setup should be easy, but I'm more than happy
> to run tests, my problem is the core code has changed so drastically
> since I ACTUALLY did bug fixes at that level that I don't understand the
> current methods :(
> 
> I can understand this new patch but I still need to back-pedal the old
> one. The only bit I'm not quite following is the switching between
> 'NULL' and '0' as I'm not sure why you are switching to '0' for some
> handles that are currently 'NULL' and then defaulting others which were
> '0' to 'NULL'  but I think it's that we are now passing a pointer rather
> than a handle?
> 
complier wanrning about handle are int

Anyway, this patch is not finish,  I hope I can finish this whole work in this 
week

Will update here when it is done

Thanks
> I need to re-sync my repository with git.php.net then at least I can
> track and roll back changes ... I'll get back to this later
> 
> -- 
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

Re: [PHP-DEV] Travis CI is failing

[Xinchen Hui]

Hey:

On Tue, Dec 15, 2015 at 7:58 PM, Lior Kaplan <lio...@zend.com> wrote:

> Hi,
>
> Travis CI reports show quite a lot of failures with recent commits to few
> of the branches.
> From a quick look it fails due to tests and not due to compilation issues.
>
> Please check the status of the build/tests after your commits:
> https://travis-ci.org/php/php-src/branches
>
> At the moment ext/session/tests/bug32330.phpt fails for 5.6, 7.0 and
> master.
>
most of them relates to session,  Yasuo, could you please have a look
into them?

thanks

>
> Thanks,
>
> Kaplan
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Re: static:: and PHP 7 (from bug #70997)

[Xinchen Hui]

Hey：

> On Nov 30, 2015, at 22:48, Rowan Collins  wrote:
> 
> Andreas Heigl wrote on 30/11/2015 12:23:
>>> Am 30.11.15 um 13:18 schrieb Peter Cowburn:
>>> class A {
 const TEST = false;
 public function test() {
 var_dump(static::TEST);
 }
 }
 
 class B extends A {
 const TEST = true;
 
 public function test() {
 A::test();
 }
 }
 
 $b = new B;
 $b->test();
>> You are calling explicitly A::test().
>> 
>> When you call parent::test() everything works as you'd expect it.
>> 
>> Have a look at https://3v4l.org/RCrRd
>> 
>> Apart from that you are calling an instance-method as a static method by
>> using A::test().
> 
> This appears to be the crucial thing: if you declare the test() method as 
> static in both classes, it returns false in all versions: 
> https://3v4l.org/hJoor
> 
> It's almost like A::test() is now interpreted as a static call, rather than a 
> "scope resolution" of the instance method, but $this is still available, so 
> it's not quite as simple as that: https://3v4l.org/qbT3j
> 
dmitry has committed a fix, please have a look

Thanks
> Regards,
> -- 
> Rowan Collins
> [IMSoP]
> 
> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Xinchen Hui]

Hey:

On Wed, Nov 25, 2015 at 5:57 PM, Nikita Popov <nikita@gmail.com> wrote:

> On Wed, Nov 25, 2015 at 4:47 AM, Xinchen Hui <larue...@php.net> wrote:
>
>> Hey:
>>
>>
>>
>> On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand <bobw...@hotmail.com> wrote:
>>
>> > > Am 24.11.2015 um 20:30 schrieb Matteo Beccati <p...@beccati.com>:
>> > >
>> > > On 24/11/2015 18:50, Andrea Faulds wrote:
>> > >> There's no syntax change. We'd be adding another fatal error to
>> > >> zend_compile.c triggered by a flag on the token. No messing around
>> with
>> > >> the parser.
>> > >>
>> > >> I understand your concern about the risk, but it's the kind of change
>> > >> that wouldn't break anything without it being tremendously obvious.
>> > >
>> > > I agree and we should be still in time for RC8.
>> > >
>> > >
>> > > Cheers
>> > > --
>> > > Matteo Beccati
>> >
>> > Hey,
>> >
>> > I fixed the issue via
>> >
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
>> >
>> > I think too this should go into PHP 7.0.0 as it is some type of a
>> language
>> > related change (even if not directly failing in parser...)
>> >
>> >
>> I've made a improvement to the fix(
>>
>> https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899
>> )
>> ,
>>
>> before this, \array will result a syntax , but \int result a compiler
>> error, which seems a little in-consistent.
>>
>
> Imho this additional change is not necessary, it only makes the parser
> more complicated.
>
> However something missing from the original patch is handling of relative
> names like namespace\int. Instead of checking for ast->attr == ZEND_NAME_FQ
> it should check for ast->attr != ZEND_NAME_NOT_FQ.
>

PS: However, namespace\int will result error while checking valid
classname, as int is reserved keywords.

so I think check for == ZEND_NAME_FQ is enough here.

thanks

>
>

>
> Nikita
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Xinchen Hui]

Hey:


On Wed, Nov 25, 2015 at 5:57 PM, Nikita Popov <nikita@gmail.com> wrote:

> On Wed, Nov 25, 2015 at 4:47 AM, Xinchen Hui <larue...@php.net> wrote:
>
>> Hey:
>>
>>
>>
>> On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand <bobw...@hotmail.com> wrote:
>>
>> > > Am 24.11.2015 um 20:30 schrieb Matteo Beccati <p...@beccati.com>:
>> > >
>> > > On 24/11/2015 18:50, Andrea Faulds wrote:
>> > >> There's no syntax change. We'd be adding another fatal error to
>> > >> zend_compile.c triggered by a flag on the token. No messing around
>> with
>> > >> the parser.
>> > >>
>> > >> I understand your concern about the risk, but it's the kind of change
>> > >> that wouldn't break anything without it being tremendously obvious.
>> > >
>> > > I agree and we should be still in time for RC8.
>> > >
>> > >
>> > > Cheers
>> > > --
>> > > Matteo Beccati
>> >
>> > Hey,
>> >
>> > I fixed the issue via
>> >
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
>> >
>> > I think too this should go into PHP 7.0.0 as it is some type of a
>> language
>> > related change (even if not directly failing in parser...)
>> >
>> >
>> I've made a improvement to the fix(
>>
>> https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899
>> )
>> ,
>>
>> before this, \array will result a syntax , but \int result a compiler
>> error, which seems a little in-consistent.
>>
>
> Imho this additional change is not necessary, it only makes the parser
> more complicated.
>
> However something missing from the original patch is handling of relative
> names like namespace\int. Instead of checking for ast->attr == ZEND_NAME_FQ
> it should check for ast->attr != ZEND_NAME_NOT_FQ.
>
> yeah, you are right,  namespace\array still behavior difference from
namespace\int.

I am going to revert my part.

thanks

> Nikita
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Xinchen Hui]

Hey:



On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand <bobw...@hotmail.com> wrote:

> > Am 24.11.2015 um 20:30 schrieb Matteo Beccati <p...@beccati.com>:
> >
> > On 24/11/2015 18:50, Andrea Faulds wrote:
> >> There's no syntax change. We'd be adding another fatal error to
> >> zend_compile.c triggered by a flag on the token. No messing around with
> >> the parser.
> >>
> >> I understand your concern about the risk, but it's the kind of change
> >> that wouldn't break anything without it being tremendously obvious.
> >
> > I agree and we should be still in time for RC8.
> >
> >
> > Cheers
> > --
> > Matteo Beccati
>
> Hey,
>
> I fixed the issue via
> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
>
> I think too this should go into PHP 7.0.0 as it is some type of a language
> related change (even if not directly failing in parser...)
>
>
I've made a improvement to the fix(
https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899)
,

before this, \array will result a syntax , but \int result a compiler
error, which seems a little in-consistent.

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] 7.0.0 release

[Xinchen Hui]

Hey:

On Tue, Nov 24, 2015 at 7:57 PM, Leigh <lei...@gmail.com> wrote:

> On 23 November 2015 at 21:10, Anatol Belski <weltl...@outlook.de> wrote:
>
> > a) release on 26th including all known bug fixes
> > b) do RC8, assume there are no bugs, so target 10th for RTM
> > c) do RC8, release on 3rd, expect there are no bugs come in
> > d) continue issuing release candidates till it's stable enough (needs
> > definition of stable and probably an RFC)
> >
> > I would really ask to reach a consent on either a) or c). IMO, the
> options
> > b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> > release just to release, but it is definitely harmful to slow down the
> rise.
> >
> > Thanks
> >
> > Anatol
> >
>
> I prefer a over c.
>
> As you said, we can deliver a stable and high quality 7.0.0 today. An RC
> period where you expect no bugs does not sound productive to me.
>
> We all know the "real testing" doesn't begin until it's released, and the
> best way to find what is left (things we have not found in over a year of
> development and testing), is to get more people looking at it.
>
> Delaying the release is actually delaying the discovery of bugs that affect
> real world applications that we do not have access to, and cannot test
> with. Many teams will not even start testing with 7 until it gets an
> official release.
>
I agree.

I also go for a)

thanks

>
> If something is found, it doesn't make the release any less high quality.
> Any bugs that would be found between now and the 3rd will still be found
> (and probably more), and they will still be fixed. The only difference
> would be a 0.0.1 version number.
>
> /2c
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Xinchen Hui]

g to
> RC6
> > where it was started to be tested obviously some more intensively, RC7
> > looks more like lost attention. We could go with more RC, sure. However
> in
> > that case IMO we would catch bugs at very low speed with no guarantee we
> > have a good thing at the end when we "think" it's good. This will cause
> us
> > to defer things for much longer time. Releasing on 26th (or on 3rd with
> > respect to Thanksgiving, if there are still strong concerns) were IMHO
> > convenient for this reasons.
> >
> > People that don't test RC won't start to test any later RC anyway. People
> > that don't test RC will start to use  GA and that will lead to bug
> reports,
> > in any case. So IMHO at this point we are good enough to do the first
> > release with all the known bugs fixed, with the knowledge that no
> critical
> > bugs are present, with the knowledge that community projects like Drupal
> 8,
> > Symfony, etc. report the green tests, and with intention to get people
> > waiting for GA involved.
> >
> > Regards
> >
> > Anatol
> >
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Xinchen Hui]

Hey:

On Mon, Nov 23, 2015 at 10:21 PM, Anthony Ferrara <ircmax...@gmail.com>
wrote:

> Zeev and all,
>
> On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski <z...@zend.com> wrote:
> >
> >
> >> On 23 בנוב׳ 2015, at 14:04, Joe Watkins <pthre...@pthreads.org> wrote:
> >>
> >>
> >> No one is expecting 0.0 or any version to be bug free, but the
> simplicity of the fix says nothing about the seriousness of the bug. I
> think it quite serious _because_ we are a few days from GA, had this been
> found a month ago it wouldn't seem so serious.
> >>
> >
> > No, but both the seriousness of the bug AND the simplicity of the fix
> sit squarely outside any sort of "critical" definition.
>
> Perhaps, except that this bug was known by engine maintainers for
> months. It actually took one of them saying it outright in a chat room
> for me to be like "WTFBBQ" and raising this thread.
>
> That seriously shakes confidence in stability. What else is known but
> not common knowledge? What else is not known? etc.
>
> > The bug simply has the unfortunate connotation of being associated with
> arrays, but is not - it's only about count()ing symbol tables.  The fix
> itself is very localized too and was peer reviewed, so I don't feel as if
> we'd be living on the edge of we'd be releasing without an extra RC.
> >
> > My main concern is that of we're treating this issue as a semi blocker -
> it's almost unthinkable we won't find something of similar (small)
> magnitude in the next seven days.  That's my only concern with releasing
> next week,m.  Would people here again demand to delay, even if the impact
> is very limited - as is the case with this count() issue?  If it wasn't for
> that concern, I'd probably be in favor of delaying.
>
> The main concern of many of us is that many people here seem to be
> demonstrating a cavalier attitude around what constitutes a .0 release
> (a stable release). Of course it's going to have bugs, but it **MUST**
> be as stable as possible. The attitude by many here of "eih, it won't
> be bug free anyway, so who cares" is poison.
>
> If we delay further, we lose nothing. It's not like shipping a week
> later is going to cost anyone anything. But shipping a broken version
> WILL cost us a lot. We've been really good the past several releases
> (5.4, 5.5, 5.6) about shipping stable versions day 1. If we break that
> trend, it will shake faith. It will cost us far more.
>
> Rasmus,
>
> > I think this was mostly a PR failure on my part actually. If I/we are a
> bit more careful about how we handle similar issues and the people lurking
> with itchy Twitter trigger fingers would spend a bit more time looking into
> the details we should all be able to get along and get a good launch with
> no controversy on Dec.3.
>
> Sorry, but when you make a statement like:
>
> > Nobody is going to take a .0.0 and push it straight to production.
>
> THAT is more than a PR failure. That's a perspective failure.
>
> > And it is not going to part of any sort of LTS distro either. It's not
> like LTS distros don't pick up point releases.
>
> They don't. Debian squeeze is still pinned on 5.3.3. This causes me
> major headaches since they didn't backport serious security features,
> leading to problems today. Saying "they pick up point releases" may be
> true for some, but the history is there that has caused MANY open
> source projects a TON of pain. So it's definitely not something to
> brush off.
>
> I'm less concerned by the specific issue here than by the 2 facts that
> surround it: It was known by engine maintainers for months, and the
>
I get a little confused, who said this was known months ago?

thanks

> cavalier attitude around what defines "stable". Both of these are far
> more critical and worth delaying to "get right" than this particular
> "bug" is...
>
> Anthony
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Xinchen Hui]

Hey:

On Sun, Nov 22, 2015 at 6:47 AM, Anthony Ferrara <ircmax...@gmail.com>
wrote:

> All,
>
> It appears that in our efforts to optimize PHP 7 we've introduced an
> inconsistency into array handling. This is demonstrated by this
> script: https://3v4l.org/hVcAB
>
> $a = 1;
> unset($a);
> var_dump(count($GLOBALS), $GLOBALS);
>
> The result is that the count doesn't match the contents of the array.
>
> It also affects objects casted to arrays in certain cases.
>
> Here, the array has 1 element, but should have 0. Trying to access the
> "1" element "a" results in a notice.
>
> This means that the count is incorrect. This is due to the fact that
> the "a" element follows an IS_INDIRECT type pointing to the other
> symbol table.
>
> A potential solution would be to make count() an O(n) operation in the
> case that the hashtable is a symbol table or if it has INDIRECT
> elements. Meaning that we'd compute the real count at runtime.
>
> This obviously has performance ramifications, but we shouldn't
> sacrifice consistency and behavior for performance IMHO. Especially
> when it comes to core data structures.
>
> I think this is significant enough to be a blocker to gold and that we
> should fix it prior to release.
>

I don't think so, it's only affects symbol tables. means, it won't affects
normal arrays. like:

 1, "bar" => 2, "dummy" => 3);
unset($array["bar"]);
var_dump(count($array));
?>

anyway, I've fixed this here:
https://github.com/php/php-src/commit/eada2aa91add2de69bc5783b840a21243a7b0678

and, we maybe move this new functions  into zend_hash(as a ZEND_API),
anyway I am not sure whether it's okey for PHP-7.0.

will discuss with welting and Dmitry on Monday.

thanks

>
> Thoughts?


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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Safe Temporary Cleanup on Exception (Variable Liveness)

[Xinchen Hui]

Hey:

On Tue, Nov 10, 2015 at 7:29 PM, Dmitry Stogov <dmi...@zend.com> wrote:

>
>
> On Tue, Nov 10, 2015 at 1:42 PM, Nikita Popov <nikita@gmail.com>
> wrote:
>
>> On Tue, Nov 10, 2015 at 10:53 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>>
>>> Hi,
>>>
>>> Please take a look into
>>> https://gist.github.com/dstogov/43eaa3f3b68583877322
>>>
>>> This is variation on Bob's idea about variable liveness.
>>> The patch is incomplete. Liveness construction is still naive. However,
>>> all tests are passed.
>>>
>>> Ranges are represented by start/end/variable cartages. (I suppose this
>>> representation is more compact, than in the original proposal).
>>> In general, it's possible to use few ranges for the same variable, if
>>> its whole live range is not linear. (this is not implemented yet).
>>>
>>> Related ideas and tests are welcome.
>>>
>>> Thanks. Dmitry.
>>>
>>
>> One leak this does not cover yet is a discarded delayed return value:
>>
>> function test() {
>> try {
>> $a = [1, 2, 3];
>> return $a + [];
>> } finally {
>> throw new Exception;
>> }
>> }
>>
>> try {
>> test();
>> } catch (Exception $e) {}
>>
>> This case is a bit tricky because it violates the usual invariant that
>> all temporaries have well-defined liveness ranges (either alive or not, no
>> maybe). We'd have to change that first.
>>
>
> I see the problem. We can't statically define live-ranges for finally
> code, because we don't know where it's going to be called from.
> May be we may reconstruct this at run-time.
>
Or maybe we could separate ZEND_RETURN(_BY_REF) into two parts

the first part, set the return value to EX(return_value),  the second part
do the really leave(leave_helper).

thus, we can keep the liveness of the variable won't be intrruptted?

like:  previously we emit:   ZEND_ADD, ZEND_FAST_CALL, ZEND_RETURN.

now we emit: ZEND_ADD,  ZEND_RETURN, ZEND_FAST_CALL, ZEND_RETURN

then in HANDLE_EXCEPTION we can dtor EX(return_value) if it is
already set?

this could also fixed double return memory leak
like Zend/tests/try/bug70228.phpt

thanks

>
> Thanks. Dmitry,
>
>
>
>>
>> Nikita
>>
>>
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Safe Temporary Cleanup on Exception (Variable Liveness)

[Xinchen Hui]

On Wed, Nov 11, 2015 at 11:10 AM, Xinchen Hui <xinche...@zend.com> wrote:

> Hey:
>
> On Tue, Nov 10, 2015 at 7:29 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>>
>>
>> On Tue, Nov 10, 2015 at 1:42 PM, Nikita Popov <nikita@gmail.com>
>> wrote:
>>
>>> On Tue, Nov 10, 2015 at 10:53 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please take a look into
>>>> https://gist.github.com/dstogov/43eaa3f3b68583877322
>>>>
>>>> This is variation on Bob's idea about variable liveness.
>>>> The patch is incomplete. Liveness construction is still naive. However,
>>>> all tests are passed.
>>>>
>>>> Ranges are represented by start/end/variable cartages. (I suppose this
>>>> representation is more compact, than in the original proposal).
>>>> In general, it's possible to use few ranges for the same variable, if
>>>> its whole live range is not linear. (this is not implemented yet).
>>>>
>>>> Related ideas and tests are welcome.
>>>>
>>>> Thanks. Dmitry.
>>>>
>>>
>>> One leak this does not cover yet is a discarded delayed return value:
>>>
>>> function test() {
>>> try {
>>> $a = [1, 2, 3];
>>> return $a + [];
>>> } finally {
>>> throw new Exception;
>>> }
>>> }
>>>
>>> try {
>>> test();
>>> } catch (Exception $e) {}
>>>
>>> This case is a bit tricky because it violates the usual invariant that
>>> all temporaries have well-defined liveness ranges (either alive or not, no
>>> maybe). We'd have to change that first.
>>>
>>
>> I see the problem. We can't statically define live-ranges for finally
>> code, because we don't know where it's going to be called from.
>> May be we may reconstruct this at run-time.
>>
> Or maybe we could separate ZEND_RETURN(_BY_REF) into two parts
>
> the first part, set the return value to EX(return_value),  the second part
> do the really leave(leave_helper).
>
> thus, we can keep the liveness of the variable won't be intrruptted?
>
> like:  previously we emit:   ZEND_ADD, ZEND_FAST_CALL, ZEND_RETURN.
>
> now we emit: ZEND_ADD,  ZEND_RETURN, ZEND_FAST_CALL, ZEND_RETURN
>
s #ZEND_RETURN$#ZEND_LEAVE#

thanks

>
> then in HANDLE_EXCEPTION we can dtor EX(return_value) if it is
> already set?
>
> this could also fixed double return memory leak
> like Zend/tests/try/bug70228.phpt
>
> thanks
>
>>
>> Thanks. Dmitry,
>>
>>
>>
>>>
>>> Nikita
>>>
>>>
>>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Bug #70805 (Segmentation faults whilst running Drupal 8 test suite)

[Xinchen Hui]

Hey:



On Wed, Nov 4, 2015 at 3:58 AM, Dmitry Stogov <dmi...@zend.com> wrote:

> Hi,
>
> I think, I found the root problem of https://bugs.php.net/bug.php?id=70805
>
> unset($a) or unser($GLOBAL["a"]) triggered GC and destructors calls that
> tried to release the same global variable $a  once again. As result it's
> reference counter was decremented twice and this caused use-after-free,
> double-free, etc.
>
> The proposed cumulative fix for all related problems:
>
> https://gist.github.com/dstogov/7aa9d24876e2b3fce8c5
>
> Xinchen, could you please review and verify this once again,
> then add necessary tests and commit.
>
No problem, all issues we met are resovled , thanks :)

tested and committed.

and aslo thanks the fabian who provides us ssh access to a reproducible box
(it's really hard to reproduce locally)

thanks!

>
> Thanks. Dmitry.
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Speed up fetching of class entries for self:: parent:: and static:: (Bob's idea)

[Xinchen Hui]

Hey:

On Wed, Oct 28, 2015 at 2:11 PM, Bob Weinand <bobw...@hotmail.com> wrote:

>
> Am 28.10.2015 um 05:20 schrieb Dmitry Stogov <dmi...@zend.com>:
>
> What is the general impression from the patch?
> Should we commit it (with minor fixes and/or additional optimisations)?
> Bob, do you see performance improvement on your app?
>
> Thanks. Dmitry.
> On Oct 27, 2015 4:14 PM, "Dmitry Stogov" <dmi...@zend.com> wrote:
>
>> Hi,
>>
>> Please take a look: https://github.com/php/php-src/pull/1604
>> The speed improvement on real-life is insignificant.
>> VM size is increased by 10KB.
>>
>> I don't have a strong opinion, if this should go into master or not.
>>
>> Thanks. Dmitry.
>>
>
> In general I like the patch, if only for the reason that it splits up the
> monster zend_fetch_var_address_helper actually was into two helpers…
>
> I benchmarked https://github.com/amphp/aerys/blob/master/lib/HPack.php with
> the following code:
>
> // Two example request headers from RFC 7541
> $data1 = hex2bin(str_replace(" ", "", "8286 8441 8cf1 e3c2 e5f2 3a6b a0ab
> 90f4 ff"));
> $data2 = hex2bin(str_replace(" ", "", "8286 84be 5886 a8eb 1064 9cbf"));
>
> for ($i = 0; $i < 1e5; $i++) {
> $obj = new HPack;
> $obj->decode($data1);
> $obj->decode($data2);
> }
>
> and got 6.27 vs. 6.01 seconds (4%). With the one or other optimization
> (like mentioned in PR: not doing a zend_fetch_class() on each call, maybe
> more), it'll be probably even more.
>
4% is also a significant improvement.

I 'd like to see it to be committed to master branch, we can keep do
something opts base on this after it merged.

thanks

>
> (I realize there's a lot overhead, but that's because I try to have a not
> too synthetic benchmark; but at least these methods are the bottleneck of
> most HTTP/2 traffic in this server app, so, if I can speed these up, it
> will be significant.)
>
> Bob
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Issues with exceptions and overloading opcodes

[Xinchen Hui]

Hey:

On Mon, Oct 26, 2015 at 8:11 PM, Dmitry Stogov <dmi...@zend.com> wrote:

> Hi,
>
> I'm going to re-fix the problem with the following patch:
>
> https://gist.github.com/dstogov/1eb77a9f2ff7dd807dd1
>
thanks, sorry I was busy last week, plan to do it tonight, but seems you
already fixed it. :)

thanks

>
>
> Thanks. Dmitry.
>
> On Thu, Oct 22, 2015 at 5:43 AM, Xinchen Hui <larue...@php.net> wrote:
>
>> Hey:
>>
>>
>>
>> On Wed, Oct 21, 2015 at 10:38 PM, Derick Rethans <der...@php.net> wrote:
>>
>>> On Tue, 20 Oct 2015, Bob Weinand wrote:
>>>
>>> > > Am 20.10.2015 um 18:08 schrieb Derick Rethans <der...@php.net>:
>>> > >
>>> > > On Tue, 20 Oct 2015, Bob Weinand wrote:
>>> > >
>>> > >>> Am 20.10.2015 um 17:11 schrieb Xinchen Hui <larue...@php.net>:
>>> > >>>
>>> > >>> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <der...@php.net
>>> <mailto:der...@php.net>> wrote:
>>> > >>>
>>> > >>>> When hacking on Xdebug for PHP 7, I ran into some issues where
>>> > >>>> PHP would just spin around. This happens when there is an
>>> > >>>> exception, and I use overloaded opcodes. I wrote a small example
>>> > >>>> extension at
>>> > >>>> https://github.com/derickr/php-minimal-opcode-overloading-example
>>> > >>>> with a test case (
>>> > >>>>
>>> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
>>> > >>>> ) that shows that something is looping in executing opcodes, as
>>> > >>>> the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
>>> > >>>> believe this is a recent enough change, as it only started
>>> > >>>> happening after I upgraded from about RC1 to latest master.
>>> > >>>>
>>> > >>>> Would you care to have a look?
>>> > >>>>
>>> > >>> This is introduced by a fix made by Bob,
>>> > >>> https://github.com/php/php-src/commit/808f62bb
>>> > >>> <https://github.com/php/php-src/commit/808f62bb>
>>> > >>>
>>> > >>> Bob, I am going to revert this for now, since you didn't include a
>>> > >>> test script to show where the problem was, I am not sure why you
>>> > >>> made this?
>>> > >>
>>> > >> I didn't add any test case as we don't have any APIs in php-src
>>> > >> using that user_opcode handler. I discussed the change back then
>>> > >> with Dmitry and committed with his review.
>>> > >>
>>> > >> It concretely broke uopz which might throw an exception itself. And
>>> > >> in turn we realized that for integrity we need to ensure that
>>> > >> opline == EX(opline) else we'll end up with different behavior in
>>> > >> global register builds and normal builds.
>>> > >>
>>> > >> In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
>>> > >> need to, have a special handling for it, but never directly
>>> > >> dispatch to it). It is quite special being the only opcode actually
>>> > >> allowing EG(exception) to be non-NULL at the start of it.
>>> > >>
>>> > >> You are doing an #ifdef ZTS to exempt it… why don't you always
>>> > >> exempt it?
>>> > >
>>> > > Even if I do (like I've just pushed into the extension), the test
>>> > > still fails because the code loops. So you did break something.
>>> >
>>> > Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
>>> >
>>> > … maybe I should write
>>> >
>>> > if (EG(exception)
>>> >  && opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode !=
>>> ZEND_CATCH
>>> >  && ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN
>>> && ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
>>> > HANDLE_EXCEPTION();
>>> > }
>>> >
>>> > to allow dispatching for these two opcodes too?
>>>
>>> I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
>>>
>>> The commit which cause this problem has been reverted,  so this is
>> resolved , and regarding the problem which is commit tried to fixed, we
>> will find a better way to re-fix that.
>>
>> thanks
>>
>>> cheers,
>>> Derick
>>
>>
>>
>>
>> --
>> Xinchen Hui
>> @Laruence
>> http://www.laruence.com/
>>
>
>


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] few questions about op_array

[Xinchen Hui]

Hey Lin:

On Fri, Oct 23, 2015 at 3:31 PM, Lin Yo-An <cornelius.h...@gmail.com> wrote:

> Hi Dmitry,
>
>
> I changed and tested it, and it looks like it gains some improvements. how
> do you compare the benchmark result? is there a tool doing it?
>
> I currently do:
>
> ./sapi/cli/php Zend/bench.php
>
> The result:
>
> https://gist.github.com/4bbc33b7b5dcedc6bd66
>
Acutally, simply bench.php testing is very un-stable. in generally, we
prefer using real-life app to test, like wordpress.

Basically, we use callgrind to collect the IRs ,  like valgrind
--tool=callgrind --instr-atstart=yes php-cgi -T 100 wordpress/index.php ( I
may type args wrong).

But in this case(cache friendly), you may try to use perf to collect cache
miss changing.

thanks

>
>
>
> On Fri, Oct 23, 2015 at 12:39 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>>
>> On Oct 22, 2015 3:45 PM, "Lin Yo-An" <cornelius.h...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> >
>> > I am looking into zend op_array structure, and few questions raised in
>> my mind:
>> >
>> > 1. Why op_array->refcount uses *uint32 instead of uint32, is there a
>> reason? if we can replace it with uint32, then we might save one emalloc
>> call for memory allocation for every op_array allocation?
>>
>> We may have few different op_array structures with the same opcodes but
>> with different names for example. So just uint32won't work.
>>
>> >
>> > 2. There are also a lot of information saved in the op_array structure,
>> if we can move line_start, line_end, doc_comments...etc into an external
>> structure, then we might be able to reduce the op_array size and decrease
>> the cache miss? is it doable?
>>
>> I'm not sure if patritioning data of op_array, into frequntly and rarely
>> used, may make any significant difference. Because we usually work only
>> with a single instance of op_array in each moment. Fields reordering alrecy
>> helped to reduce cache-misses. But I may be wrog :)
>>
>> Thanks. Dmitry.
>>
>> >
>> >
>> >
>> > Cheers,
>> > Yo-An Lin
>> > https://github.com/c9s
>> >
>>
>
>
>
> --
> Best Regards,
>
> Yo-An Lin
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Issues with exceptions and overloading opcodes

[Xinchen Hui]

Hey:



On Wed, Oct 21, 2015 at 10:38 PM, Derick Rethans <der...@php.net> wrote:

> On Tue, 20 Oct 2015, Bob Weinand wrote:
>
> > > Am 20.10.2015 um 18:08 schrieb Derick Rethans <der...@php.net>:
> > >
> > > On Tue, 20 Oct 2015, Bob Weinand wrote:
> > >
> > >>> Am 20.10.2015 um 17:11 schrieb Xinchen Hui <larue...@php.net>:
> > >>>
> > >>> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <der...@php.net
> <mailto:der...@php.net>> wrote:
> > >>>
> > >>>> When hacking on Xdebug for PHP 7, I ran into some issues where
> > >>>> PHP would just spin around. This happens when there is an
> > >>>> exception, and I use overloaded opcodes. I wrote a small example
> > >>>> extension at
> > >>>> https://github.com/derickr/php-minimal-opcode-overloading-example
> > >>>> with a test case (
> > >>>>
> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
> > >>>> ) that shows that something is looping in executing opcodes, as
> > >>>> the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
> > >>>> believe this is a recent enough change, as it only started
> > >>>> happening after I upgraded from about RC1 to latest master.
> > >>>>
> > >>>> Would you care to have a look?
> > >>>>
> > >>> This is introduced by a fix made by Bob,
> > >>> https://github.com/php/php-src/commit/808f62bb
> > >>> <https://github.com/php/php-src/commit/808f62bb>
> > >>>
> > >>> Bob, I am going to revert this for now, since you didn't include a
> > >>> test script to show where the problem was, I am not sure why you
> > >>> made this?
> > >>
> > >> I didn't add any test case as we don't have any APIs in php-src
> > >> using that user_opcode handler. I discussed the change back then
> > >> with Dmitry and committed with his review.
> > >>
> > >> It concretely broke uopz which might throw an exception itself. And
> > >> in turn we realized that for integrity we need to ensure that
> > >> opline == EX(opline) else we'll end up with different behavior in
> > >> global register builds and normal builds.
> > >>
> > >> In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
> > >> need to, have a special handling for it, but never directly
> > >> dispatch to it). It is quite special being the only opcode actually
> > >> allowing EG(exception) to be non-NULL at the start of it.
> > >>
> > >> You are doing an #ifdef ZTS to exempt it… why don't you always
> > >> exempt it?
> > >
> > > Even if I do (like I've just pushed into the extension), the test
> > > still fails because the code loops. So you did break something.
> >
> > Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
> >
> > … maybe I should write
> >
> > if (EG(exception)
> >  && opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode !=
> ZEND_CATCH
> >  && ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN
> && ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
> > HANDLE_EXCEPTION();
> > }
> >
> > to allow dispatching for these two opcodes too?
>
> I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
>
> The commit which cause this problem has been reverted,  so this is
resolved , and regarding the problem which is commit tried to fixed, we
will find a better way to re-fix that.

thanks

> cheers,
> Derick




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Issues with exceptions and overloading opcodes

[Xinchen Hui]

+bob

On Tue, Oct 20, 2015 at 11:11 PM, Xinchen Hui <larue...@php.net> wrote:

> Hey:
>
>
>
> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <der...@php.net> wrote:
>
>> Hi!
>>
>> When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
>> just spin around. This happens when there is an exception, and I use
>> overloaded opcodes. I wrote a small example extension at
>> https://github.com/derickr/php-minimal-opcode-overloading-example with a
>> test case
>> (
>> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
>> )
>> that shows that something is looping in executing opcodes, as the
>> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
>> is a recent enough change, as it only started happening after I upgraded
>> from about RC1 to latest master.
>>
>> Would you care to have a look?
>>
> This is introduced by a fix made by Bob,
> https://github.com/php/php-src/commit/808f62bb
>
> Bob, I am going to revert this for now, since you didn't include a test
> script to show where the problem was,  I am not sure why you made this?
>
>
> thanks
>
>>
>> cheers,
>> Derick
>>
>> --
>> http://derickrethans.nl | http://xdebug.org
>> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
>> twitter: @derickr and @xdebug
>> Posted with an email client that doesn't mangle email: alpine
>>
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

[PHP-DEV] Re: Issues with exceptions and overloading opcodes

[Xinchen Hui]

Hey:



On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <der...@php.net> wrote:

> Hi!
>
> When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
> just spin around. This happens when there is an exception, and I use
> overloaded opcodes. I wrote a small example extension at
> https://github.com/derickr/php-minimal-opcode-overloading-example with a
> test case
> (
> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
> )
> that shows that something is looping in executing opcodes, as the
> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
> is a recent enough change, as it only started happening after I upgraded
> from about RC1 to latest master.
>
> Would you care to have a look?
>
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb

Bob, I am going to revert this for now, since you didn't include a test
script to show where the problem was,  I am not sure why you made this?


thanks

>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by ReflectionFunctionAbstract::getClosure()

[Xinchen Hui]

Hey:

On Tue, Oct 13, 2015 at 6:12 AM, Anatol Belski <anatol@belski.net>
wrote:

>
>
> > -Original Message-
> > From: Nikita Popov [mailto:nikita@gmail.com]
> > Sent: Monday, October 12, 2015 10:33 PM
> > To: Anatol Belski <anatol@belski.net>
> > Cc: Dmitry Stogov <dmi...@zend.com>; PHP internals <
> internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by
> > ReflectionFunctionAbstract::getClosure()
> >
> > On Mon, Oct 12, 2015 at 10:22 PM, Anatol Belski <anatol@belski.net>
> > wrote:
> >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Nikita Popov [mailto:nikita@gmail.com]
> > > > Sent: Monday, October 12, 2015 8:57 PM
> > > > To: Dmitry Stogov <dmi...@zend.com>
> > > > Cc: PHP internals <internals@lists.php.net>; Andrea Faulds
> > > > <a...@ajf.me>;
> > > Stas
> > > > Malyshev <smalys...@sugarcrm.com>; Bob Weinand <bwo...@php.net>;
> > > > Anatol Belski <anatol@belski.net>
> > > > Subject: [PHP-DEV] Re: Forbid rebinding scope of closures created by
> > > > ReflectionFunctionAbstract::getClosure()
> > > >
> > > > > It would be great, if we stop any commits into PHP-7.0 except for
> > > > critical fixes now
> > > >
> > > > Maybe keep PHP-7.0 open (or as open as release branches usually
> > > > are),
> > > but from
> > > > now on only cherry-pick critical fixes into PHP-7.0.0 (instead of
> > > > merging everything)?
> > > >
> > > I commit myself to Dmitry's words. What matters today and especially
> > > after
> > > RC5 is the stability. Today we should invest into testing and bug
> > > fixes more than into improvements (aka fixes to something that is not
> > > broken). It really matters for the quality of the final. That's the
> > > message to convey probably.
> > >
> >
> > To rephrase my question: Should we treat PHP-7.0 the same way we treat
> > PHP-5.6 and other release branches (i.e. all kinds of bug fixes are
> okay, even if
> > it's just improving a test or fixing some inconsequential behavior), or
> do you
> > want to limit the PHP-7.0 branch to actually critical fixes now? From
> what you
> > say, I assume the former rather than the latter?
> >
> Talking about "critical" I meant usual definitions as something that
> causes memory corruptions, data loss, big functional impact, security
> flaws, etc.
>
agree, bugs

>
> The tricky point with 7.0 right now is that it's a lot of new stuff with
> very high expectations standing short before final. Coupling this with the
> "critical" from above, the definition I would make were - it is a) critical
> and b) can be fixed properly and cannot wait until after the final release.
> The dev time spent to fix something after 7.0 final is indeed lost for the
> 7.0 final. Any new code short before final increases the instability risk
> of the final.
>
> Fe small functional regressions are probably not always critical. If a
> (even small) functional regression breaks a lot, it is critical. If a
> functional regression breaks a rare use case - it is not critical. If
> improving a test helps to cover some critical code - so yes, it is critical
> as well. Anything that is critical can involve anything you've mentioned
> like adding tests or code.
>
hmm, I understand your ideas, but I think maybe we should forbid such
things as well for this moment, because it make things complicated to
judge(if it is critical or not), such things can goes to 7.1

let's only allows bugs fix (as you mentioned above) to be committed into
PHP-7.0 before the final release of its

thanks

>
> Hopefully I could express myself better now. Cherry-pick is of course a
> solution, but IMHO it is important every dev to understand the unique
> situation we currently have to face. It is better to avoid cherry-picking
> in favor of the "mission aware" code :)


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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] taint

[Xinchen Hui]

Hey:

On Thu, Sep 17, 2015 at 2:37 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
>>> Taint is blacklisting.
>>>
>> Last time I checked marking all user input as tainted and requiring
>> "untainting" before usage in sensitive functions is whitelisting and not
>> blacklisting.
>
> I would say it's neither - whitelisting is an explicit check (or fixing,
> to ensure) that the input matches certain conditions (blacklisting is
> the same but "does not match") - but taint actually doesn't do that. All
> it does is ensure you did *some* data fixing - it can't really ensure
> *what* you did, what were the results of the fixing and if the fixing
> you employed match the security context in which you are using the data.
> So taint does only the half of the work of either blacklist or whitelist
> - it ensures you didn't forget to do _something_, where something could
> be white-list. Or be something useless at all. That's the main thing one
> needs to remember when using taint - it doesn't do any work, it just
> reminds you to do work, and you still have to ensure the work is right.


Just for the record , Taint is ready for PHP7:
https://github.com/laruence/taint/tree/php7

thanks
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] Re: [PHP-CVS] com php-src: Added an experemental ability to move PHP code pages (PHP TEXT segment) into HUGE pages. PHP should be configured and built with --enable-huge-code-pages, OS shoul

[Xinchen Hui]

  }
>> +#endif
>> +   if (ret == start) {
>> +   memcpy(start, mem, size);
>> +   mprotect(start, size, PROT_READ | PROT_EXEC);
>> +   }
>> +   munmap(mem, size);
>> +   close(fd);
>> +
>> +   return (ret == start) ? 0 : -1;
>> +}
>> +
>> +static void accel_move_code_to_huge_pages(void)
>> +{
>> +   FILE *f;
>> +   long unsigned int huge_page_size = 2 * 1024 * 1024;
>> +
>> +   f = fopen("/proc/self/maps", "r");
>> +   if (f) {
>> +   long unsigned int  start, end, offset, inode;
>> +   char perm[5], dev[6], name[MAXPATHLEN];
>> +   int ret;
>> +
>> +   ret = fscanf(f, "%lx-%lx %4s %lx %5s %ld %s\n", ,
>> , perm, , dev, , name);
>> +   if (ret == 7 && perm[0] == 'r' && perm[1] == '-' &&
>> perm[2] == 'x' && name[0] == '/') {
>> +   long unsigned int  seg_start =
>> ZEND_MM_ALIGNED_SIZE_EX(start, huge_page_size);
>> +   long unsigned int  seg_end = (end &
>> ~(huge_page_size-1L));
>> +
>> +   if (seg_end > seg_start) {
>> +   zend_accel_error(ACCEL_LOG_DEBUG, "remap
>> to huge page %lx-%lx %s \n", seg_start, seg_end, name);
>> +   accel_remap_huge_pages((void*)seg_start,
>> seg_end - seg_start, name, offset + seg_start - start);
>> +   }
>> +   }
>> +   fclose(f);
>> +   }
>> +}
>> +# endif
>> +#endif /* HAVE_HUGE_CODE_PAGES */
>> +
>>  static int accel_startup(zend_extension *extension)
>>  {
>> zend_function *func;
>> @@ -2505,6 +2591,16 @@ static int accel_startup(zend_extension *extension)
>> accel_gen_system_id();
>>  #endif
>>
>> +#ifdef HAVE_HUGE_CODE_PAGES
>> +   if (ZCG(accel_directives).enable_huge_code_pages &&
>> +   (strcmp(sapi_module.name, "cli") == 0 ||
>> +strcmp(sapi_module.name, "cli-server") == 0 ||
>> +strcmp(sapi_module.name, "cgi-fcgi") == 0 ||
>> +strcmp(sapi_module.name, "fpm-fcgi") == 0)) {
>> +   accel_move_code_to_huge_pages();
>> +   }
>> +#endif
>> +
>> /* no supported SAPI found - disable acceleration and stop
>> initialization */
>> if (accel_find_sapi() == FAILURE) {
>> accel_startup_ok = 0;
>> diff --git a/ext/opcache/ZendAccelerator.h b/ext/opcache/ZendAccelerator.h
>> index 6ce4613..da3fc66 100644
>> --- a/ext/opcache/ZendAccelerator.h
>> +++ b/ext/opcache/ZendAccelerator.h
>> @@ -219,6 +219,9 @@ typedef struct _zend_accel_directives {
>> zend_bool  file_cache_only;
>> zend_bool  file_cache_consistency_checks;
>>  #endif
>> +#ifdef HAVE_HUGE_CODE_PAGES
>> +   zend_bool  enable_huge_code_pages;
>> +#endif
>>  } zend_accel_directives;
>>
>>  typedef struct _zend_accel_globals {
>> diff --git a/ext/opcache/config.m4 b/ext/opcache/config.m4
>> index 856f24a..d8f84e2 100644
>> --- a/ext/opcache/config.m4
>> +++ b/ext/opcache/config.m4
>> @@ -8,12 +8,19 @@ PHP_ARG_ENABLE(opcache, whether to enable Zend OPcache
>> support,
>>  PHP_ARG_ENABLE(opcache-file, whether to enable file based caching
>> (experimental),
>>  [  --enable-opcache-file   Enable file based caching], no)
>>
>> +PHP_ARG_ENABLE(huge-code-pages, whether to enable copying PHP CODE pages
>> into HUGE PAGES (experimental),
>> +[  --enable-huge-code-pages Enable copying PHP CODE pages into HUGE
>> PAGES], no)
>> +
>>  if test "$PHP_OPCACHE" != "no"; then
>>
>>if test "$PHP_OPCACHE_FILE" == "yes"; then
>>  AC_DEFINE(HAVE_OPCACHE_FILE_CACHE, 1, [Define to enable file based
>> caching (experimental)])
>>fi
>>
>> +  if test "$PHP_HUGE_CODE_PAGES" == "yes"; then
>> +AC_DEFINE(HAVE_HUGE_CODE_PAGES, 1, [Define to enable copying PHP CODE
>> pages into HUGE PAGES (experimental)])
>> +  fi
>> +
>>AC_CHECK_FUNC(mprotect,[
>>  AC_DEFINE(HAVE_MPROTECT, 1, [Define if you have mprotect() function])
>>])
>> diff --git a/ext/opcache/zend_accelerator_module.c
>> b/ext/opcache/zend_accelerator_module.c
>> index eb93f59..5dfa8c1 100644
>> --- a/ext/opcache/zend_accelerator_module.c
>> +++ b/ext/opcache/zend_accelerator_module.c
>> @@ -309,6 +309,9 @@ ZEND_INI_BEGIN()
>> STD_PHP_INI_ENTRY("opcache.file_cache_only"   , "0"
>> , PHP_INI_SYSTEM, OnUpdateBool,  accel_directives.file_cache_only,
>> zend_accel_globals, accel_globals)
>> STD_PHP_INI_ENTRY("opcache.file_cache_consistency_checks" , "1"
>> , PHP_INI_SYSTEM, OnUpdateBool,
>> accel_directives.file_cache_consistency_checks, zend_accel_globals,
>> accel_globals)
>>  #endif
>> +#ifdef HAVE_HUGE_CODE_PAGES
>> +   STD_PHP_INI_BOOLEAN("opcache.enable_huge_code_pages"  , "1"
>> , PHP_INI_SYSTEM, OnUpdateBool,
>> accel_directives.enable_huge_code_pages,zend_accel_globals,
>> accel_globals)
>> +#endif
>>  ZEND_INI_END()
>>
>>  static int filename_is_in_cache(zend_string *filename)
>>
>>
>> --
>> PHP CVS Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiersin PHP 7.1+

[Xinchen Hui]

Hey:

On Tue, Sep 8, 2015 at 9:23 AM, Ryan Pallas <derokor...@gmail.com> wrote:
>
> On Mon, Sep 7, 2015 at 7:11 PM, Xinchen Hui <larue...@gmail.com> wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>> > On Sep 8, 2015, at 02:09, Andrea Faulds <a...@ajf.me> wrote:
>> >
>> > Hi Stas,
>> >
>> > Stanislav Malyshev wrote:
>> >>
>> >> Private and protected methods and properties are private for a reason -
>> >> they may be radically changed or gone when the code is changing, and
>> >> thus external code should not rely on them, and the way to ensure it is
>> >> to deny that code access to them. However, I have hard time seeing how
>> >> that would apply to constants - they shouldn't really change,
>> >
>> > Why not? A constant's value doesn't change at runtime, but nothing stops
>> > you changing the value in a new version. A real-world example for you: 
>> > phpng
>> > changed the values of the IS_* constants in the Zend Engine.
>> >
>> >> and if
>> >> they do, they either shouldn't be constant, or something in your world
>> >> changed fundamentally (i.e. scientists discovered that PI actually
>> >> equals to 4).
>> >
>> > Constants in code aren't necessarily natural constants.
>> >
>> > I wonder if you find in your code constant that you need
>> >> to hide because you foresee it changing - should it really be a
>> >> constant
>> >> at all?
>> >
>> > If I have a value specified in the source code which will not change at
>> > runtime, and which I don't want to expose as part of my public API... what
>> > exactly do you propose it should be? I don't see why a constant isn't
>> > fitting.
>> >
>> public static final as Java does
>>
>
> https://3v4l.org/KX5jQ
>> PHP Fatal error:  Cannot declare property Foo::$Bar final, the final
>> modifier is allowed only for methods and classes in - on line 4
>
> So there is no way to create an immutable property with a visibility
> modifier, unless you're suggesting that's what the RFC should be instead.
Ah, I thought it should work , so sad..

thanks



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Re: [RFC] [Concept] Class Constant visibility modifiersin PHP 7.1+

[Xinchen Hui]

Sent from my iPhone

> On Sep 8, 2015, at 02:09, Andrea Faulds  wrote:
> 
> Hi Stas,
> 
> Stanislav Malyshev wrote:
>> 
>> Private and protected methods and properties are private for a reason -
>> they may be radically changed or gone when the code is changing, and
>> thus external code should not rely on them, and the way to ensure it is
>> to deny that code access to them. However, I have hard time seeing how
>> that would apply to constants - they shouldn't really change,
> 
> Why not? A constant's value doesn't change at runtime, but nothing stops you 
> changing the value in a new version. A real-world example for you: phpng 
> changed the values of the IS_* constants in the Zend Engine.
> 
>> and if
>> they do, they either shouldn't be constant, or something in your world
>> changed fundamentally (i.e. scientists discovered that PI actually
>> equals to 4).
> 
> Constants in code aren't necessarily natural constants.
> 
> I wonder if you find in your code constant that you need
>> to hide because you foresee it changing - should it really be a constant
>> at all?
> 
> If I have a value specified in the source code which will not change at 
> runtime, and which I don't want to expose as part of my public API... what 
> exactly do you propose it should be? I don't see why a constant isn't fitting.
> 
public static final as Java does

Thanks
> Thanks.
> 
> -- 
> Andrea Faulds
> http://ajf.me/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Xinchen Hui]

Hey:

On Tue, Sep 1, 2015 at 2:51 PM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi!
>
>> I agree that at first it will feel a little bit weird, especially
>> given that PHP in general lacks syntactic sugar (we still don't have a
>> short-hand to initialize stdclass objects). We introduced [] back in
>> 5.4, and largely it has made readability FAR better (despite some
>> people saying it wouldn't at the time).
>
> That doesn't mean now we have to drop all keywords and switch to
> write-only style. Even [] was somewhat controversial, though it is the
> most elementary syntax construct. Function call is in no way elementary
> - it has non-trivial structure, and obscuring this structure by removing
> keywords does not help readability.
>
>> tool isn't always appropriate in all situations. You can craft code
>> that makes this new syntax look unreadable. But you can craft code
>
> The problem is not that I can. The problem is that anybody can, and a
> lot of people would, unwittingly, once the expressions get more complex
> that $x+1.
>
>> that makes this look far more readable.
>>
>> Example:
>>
>> function partial(callable $cb) {
>> return function($left) use ($cb) {
>> return function($right) use ($cb, $left) {
>> return $cb($left, $right);
>> };
>> };
>> }
>
> It is a bit verbose but pretty clear what's going on here - function
> returns a function that returns a function, and you can easily track
> which variable goes where and how it gets to the end.
>
>>
>> vs:
>>
>> function partial(callable $cb) {
>> return $left ~> $right ~> $cb($left, $right);
>> }
>
> It looks very pretty as the ASCII art, and no entry-level programmer
> would have any idea at all what these arrows actually do and how this
> thing is supposed to work. At least not without studying the manual very
> closely for extended time. That's exactly the problem. People start
> writing overly clever code that looks so pretty - and then other people
> are left scratching their heads about what actually is happening there.
> That's what I mean by write-only code.
>
>> It may look weird at first, but consider that's because you're not
>> used to the syntax. To me, the top is far harder to follow because of
>
> Of course, with enough training you can get fluent even in APL. I know
> people that are. But PHP is supposed to be on the other end of the
> spectrum.
>
>> the shear number of tokens to follow, not to mention that I need to
>> pay attention to the use-blocks which may or may not be importing
>> certain variables. The bottom reads exactly how I would expect it to.
>
> That's because you wrote it and know in advance what it is supposed to
> do. It's not a good test of readability.

+1, that is what readable(guessable) means.

thanks
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Need help finding segfault in php 7

[Xinchen Hui]

Hey:


On Thu, Aug 13, 2015 at 8:36 PM, James Gilliland neclim...@gmail.com wrote:
 So I've been trying for a couple days to narrow down this bug:
 https://bugs.php.net/bug.php?id=70242

 I can consistently recreate it with a complex test, but I have thus far not
 been able to find a pattern that helps me narrow down to a test script. I
 thought maybe I could reach out and see if I could get some help
 understanding what is happening in php and see if that has any clues.


 Seemingly important facts I've found digging through in gdb.
 1) The connection related pointers on the stmt are already freed when the
 fault happens. It looks like the statement is being freed after the
 connection and the if (S-H-server) { surrounding the failing code is not
 sufficient to catch this
 2) The trace has a spl_iterator in it so it seems like that is holding on
 to the stmt pointer. There is a IteratorIterator used on a PDO stmt in the
 code. But also in a lot of other non-triggering seemingly identical code
 and I haven't been able to get this to work.
 3) The code in shutdown_executor that is triggering this is the 6th block
 of cleanups which seems to support 1). It is the block without any
 documentation which is sort of my luck in this.

 I'm guessing there is some way I need to trick a object to hold onto a
 reference through the other cleanups or something or trigger some sort of
 reference counter quirk but I just can't find it. Any help is appreciated.

thanks for the ssh access , I finally get the reason of this bug..

I  get a simple reproduce script and quick fix. all listed in
https://bugs.php.net/bug.php?id=70272thanks=1

@dmitry: do you see a better solution ?

thanks


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Introduction and some opcache SSE related stuff

[Xinchen Hui]

Hey:


On Thu, Jul 30, 2015 at 8:24 PM, Joe Watkins pthre...@pthreads.org wrote:
 Hi Andone,

 I'm not sure why nobody has replied to you yet, we've all looked at the
 PR and spent a lot of the day yesterday discussing it.

 I've CC'd Dmitry, he doesn't always read internals, so this should get
 his attention.
Sorry for late response, and Dmitry is on vacation now. so, he
probably not be able to reply this soon.

anyway, is the performance improvement is consistently be seen?

have you tested it with some profiling tool? IR reduced or cache misses reduced?

thanks

 Lastly, very cool ... I look forward to some more cleverness ...

 Cheers
 Joe

 On Wed, Jul 29, 2015 at 3:22 PM, Andone, Bogdan bogdan.and...@intel.com
 wrote:

 Hi Guys,

 My name is Bogdan Andone and I work for Intel in the area of SW
 performance analysis and optimizations.
 We would like to actively contribute to Zend PHP project and to involve
 ourselves in finding new performance improvement opportunities based on
 available and/or new hardware features.
 I am still in the source code digesting phase but I had a look to the
 fast_memcpy() implementation in opcache extension which uses SSE intrinsics:

 If I am not wrong fast_memcpy() function is not currently used, as I
 didn't find the -msse4.2 gcc flag in the Makefile. I assume you probably
 didn't see any performance benefit so you preserved generic memcpy() usage.

 I would like to propose a slightly different implementation which uses
 _mm_store_si128() instead of _mm_stream_si128(). This ensures that copied
 memory is preserved in data cache, which is not bad as the interpreter will
 start to use this data without the need to go back one more time to memory.
 _mm_stream_si128() in the current implementation is intended to be used for
 stores where we want to avoid reading data into the cache and the cache
 pollution; in opcache scenario it seems that preserving the data in cache
 has a positive impact.

 Running php-cgi -T1 on WordPress4.1/index.php I see ~1% performance
 increase for the new version of fast_memcpy() compared with the generic
 memcpy(). Same result using a full load test with http_load on a Haswell EP
 18 cores.

 Here is the proposed pull request:
 https://github.com/php/php-src/pull/1446

 Related to the SW prefetching instructions in fast_memcpy()... they are
 not really useful in this place. There benefit is almost negligible as the
 address requested for prefetch will be needed at the next iteration (few
then maybe we don't need this in fast_memcpy? I mean it maybe used
widely if is is proven to be faster, which will be out of this
context.

thanks
 cycles later), while the time needed to get data from RAM is 100 cycles
 usually.. Nevertheless... they don't heart and it seems they still have a
 very small benefit so I preserved the original instruction and I added a
 new prefetch request for the destination pointer.

 Hope it helps,
 Bogdan




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

[Xinchen Hui]

Hey:

On Thu, Jul 30, 2015 at 8:14 PM, Joe Watkins pthre...@pthreads.org wrote:
 I find myself agreeing with Pierre; The wrong signal would be sent. History
 should teach us there is no such thing as (a) safe mode.

 Xinchen did used to work on a taint extension, I wonder why that was
 stopped ?
yes, it is https://github.com/laruence/php-taint

Anyway, I was too busy so I didn't make it supports PHP-5.6, I was
hoping someone could help(it supports 5.5 now).

it is a complex extension, and using tricky way to keep taint infos

anyway, with PHP7's new zend_string, and string flags, the
implementation will become easier.

I have a plan to make it supports PHP7..

thanks

 Worth noticing that the extension is rather complex, touching many parts of
 the engine, changing many things ... which I don't really like.

 Cheers
 Joe

 On Thu, Jul 30, 2015 at 10:14 AM, Craig Francis cr...@craigfrancis.co.uk
 wrote:

 On 30 Jul 2015, at 08:24, Lester Caine les...@lsces.co.uk wrote:

  But that is a perfect example of what I am talking about. You do not
  educate people by publishing the very thing that is wrong. You educate
  them by pointing out to them WHY the '?' was there in the first place.




 I completely agree on education, and what I'm hoping for... and this is
 how we can educate everyone :-)

 My suggestion for taints (not quite the same as the one from Matt or
 Wietse) was not to change the way good programs are created/executed, but
 simply an education device, which can also pick up mistakes that
 experienced developers make.

 While my first post on this mailing list gives a better overview:

http://news.php.net/php.internals/87207

 The original implementation suggestion is at:

https://bugs.php.net/bug.php?id=69886

 You will see that it does nothing more than create notices to say erm, do
 you want to be doing this?.

 This is something that only PHP can do, unless you can find a way of
 changing every single article / code example on the internet :-)

 So, with your example... if you want to use a variable for a table/field
 prefix, that is perfectly fine... in fact, it won't need any changes, as
 the prefix will probably be hard coded as a string within a PHP script
 (something I called ETYPE_CONSTANT).

 But if not (e.g. storing the prefix in an ini file?), then I've shown an
 example of how that can be handled with the proposed string_encoding_set
 function (something I should have probably called string_escaping_set)...
 which is simply to tell PHP that this one variable is already safe
 (something I can't see being needed very often).

 Craig





 On 30 Jul 2015, at 08:24, Lester Caine les...@lsces.co.uk wrote:

  On 29/07/15 16:11, Craig Francis wrote:
  I completely disagree... prepared statements are just as vulnerable,
 and so are ORM's.
 
  You can push developers towards these solutions, and that would be
 good, but you are completely blind if you think an uneducated developer
 won't do:
 
   if ($stmt = $mysqli-prepare(SELECT District FROM City WHERE
 Name= . $_GET['name'])) {
   }
 
  But that is a perfect example of what I am talking about. You do not
  educate people by publishing the very thing that is wrong. You educate
  them by pointing out to them WHY the '?' was there in the first place.
 
  Since the taint extension only covers mysql and sqlite it's of little
  use if we manage to convert 'uneducated developer' to any of the more
  secure databases, and that was one of the reasons why mysql was dropped
  from being loaded by default. Once one starts from a base of
  parametrised sql queries the lax programming methods many mysql guides
  and books continue to push can be reversed. Throwing more bloat into php
  to create 'WTF' errors just adds to a new users frustration and annoys
  experienced users who have very good reasons for building queries using
  clean variables. MANY abstraction layers use variables to add prefixes
  to table names or fields.
 
  Educate ... don't nanny ...
 
  --
  Lester Caine - G8HFL
  -
  Contact - http://lsces.co.uk/wiki/?page=contact
  L.S.Caine Electronic Services - http://lsces.co.uk
  EnquirySolve - http://enquirysolve.com/
  Model Engineers Digital Workshop - http://medw.co.uk
  Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 


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





-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] bug35437.php fails on master?

[Xinchen Hui]

Hey:



On Tue, Jul 28, 2015 at 1:50 AM, Ferenc Kovacs tyr...@gmail.com wrote:


 On Mon, Jul 27, 2015 at 6:57 PM, Stanislav Malyshev smalys...@gmail.com
 wrote:

 Hi!

 I've build current master branch and I get segfault on bug35437.phpt.
 Doesn't happen with PHP-7.0.0 branch. Anybody did anything there that
 may have caused this?
 --
 Stas Malyshev
 smalys...@gmail.com

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


 hi Stas,

 I can (only) reproduce this on my Mac, using git bisect I was able to
 pinpoint that the problem was introduced by
 0f1e87d9c18c52f91cb64267114267d239ad3488 reverting it fixes the test failure
 for me.
 Laruence, could you please look into this?
it should be fixed in
https://github.com/php/php-src/commit/16d6dfddef5ac43de3b20ffa7818d5b11f4e6a4b

could you please verify this?

thanks

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] Make debug_zval_dump prints int as long

[Xinchen Hui]

Hey:

I made a small PR about changes output of some types name in
debug_zval_dump, to make it behavior consistently with var_dump.
https://github.com/php/php-src/pull/1434

2 things are changed:

1. print int instead of long
2. print float instead of double.

RM and me are worrying about this will break some APPs unit tests
.. anyway, welting doesn't find any in github..

so,  is there any objections to merge this into PHP7.0?

thanks
-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Optimizing php_html_entities()

[Xinchen Hui]

 = microtime(true) - $start;
 echo 'Loop: '.$loop_time.\n;
 $t[] = $loop_time;
 }
 // Remove max for better approximation
 unset($t[array_search(max($t), $t)]);
 unset($t[array_search(max($t), $t)]);
 $loop_time = array_sum($t)/(ITER-2);
 echo Loop Avg: ${loop_time}\n;

 $s = 'abcdefgh';
 echo Escaping string ${s}\n;
 $t = [];
 for ($n = 0; $n  ITER; $n++) {
 $start = microtime(true);
 for ($i = 0; $i  LOOP; $i++) {
 htmlspecialchars($s);
 }
 $time = (microtime(true) - $start - $loop_time);
 echo Time: ${time}\n;
 $t[] = $time;
 }
 // Remove max for better approximation
 unset($t[array_search(max($t), $t)]);
 unset($t[array_search(max($t), $t)]);
 $time = array_sum($t)/(ITER-2);
 echo Time Avg: ${time}\n;

 $s = 12345678;
 echo Escaping integer ${s}\n;
 $t = [];
 for ($n = 0; $n  ITER; $n++) {
 $start = microtime(true);
 for ($i = 0; $i  LOOP; $i++) {
 htmlspecialchars($s);
 }
 $time = (microtime(true) - $start - $loop_time);
 echo Time: ${time}\n;
 $t[] = $time;
 }
 // Remove max for better approximation
 unset($t[array_search(max($t), $t)]);
 unset($t[array_search(max($t), $t)]);
 $time = array_sum($t)/(ITER-2);
 echo Time Avg: ${time}\n;



 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Optimizing php_html_entities()

[Xinchen Hui]

Hey:

On Tue, Jun 23, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 I'm trying to optimize php_html_entities().
 Since htmlspecialchars()/htmlentities() are sensitive function, I would
 like to ask comments before merge.

 https://github.com/php/php-src/pull/1356

 Current php_html_entities() convert int/float/etc to string, then convert
 it.
 int/float/etc is not required to be escaped. Optimize it by simply
 converting them to string.

 Simple benchmark shows about 60% execution time reduction.

 [yohgaki@dev github-php-src]$ ./php-bin b.php
 Time: 10.484607934952
 [yohgaki@dev github-php-src]$ ./php-bin b.php
 Time: 10.867615222931
 [yohgaki@dev github-php-src]$ ./php.new b.php
 Time: 3.9379420280457
 [yohgaki@dev github-php-src]$ ./php.new b.php
 Time: 4.0694711208344
 [yohgaki@dev github-php-src]$ cat b.php
 ?php
 const LOOP=1;

 $start = microtime(true);
 for ($i = 0; $i  LOOP; $i++) {
 }
 $loop_time = microtime(true) - $start;

 $start = microtime(true);
 for ($i = 0; $i  LOOP; $i++) {
 htmlspecialchars(123456790);
 }
 echo 'Time: '.(microtime(true) - $start - $loop_time).\n;
But passing an non-string to htmlspecialchars are not common used cases..

optimize not common used cases... will bring nothing to us..

thanks


 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Optimizing php_html_entities()

[Xinchen Hui]

Hey:



On Wed, Jun 24, 2015 at 8:32 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Xinchen,

 On Tue, Jun 23, 2015 at 11:33 PM, Xinchen Hui larue...@php.net wrote:

 But passing an non-string to htmlspecialchars are not common used cases..

 optimize not common used cases... will bring nothing to us..


 The reason why I looked into this in the first place is one of my friend
 complained about slow htmlspecialchars for relatively large table data.

 He said more than half of execution time is took by htmlspecialchars
 because

  - it escapes numeric values as string
  - it does not accept array value for to be escaped values

 1st is covered by this patch.
 2nd issue is covered by this FR.
   https://bugs.php.net/bug.php?id=69908

 So it brings something for us :)
Then what about strlen(number)?  are you also going to change its ZPP
to accept zval instead of string?

thanks

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Optimizing php_html_entities()

[Xinchen Hui]

Hey:

On Wed, Jun 24, 2015 at 10:35 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Xinchen,

 On Wed, Jun 24, 2015 at 11:31 AM, Xinchen Hui larue...@php.net wrote:




 On Wed, Jun 24, 2015 at 8:32 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
  Hi Xinchen,
 
  On Tue, Jun 23, 2015 at 11:33 PM, Xinchen Hui larue...@php.net wrote:
 
  But passing an non-string to htmlspecialchars are not common used
  cases..
 
  optimize not common used cases... will bring nothing to us..
 
 
  The reason why I looked into this in the first place is one of my friend
  complained about slow htmlspecialchars for relatively large table data.
 
  He said more than half of execution time is took by htmlspecialchars
  because
 
   - it escapes numeric values as string
   - it does not accept array value for to be escaped values
 
  1st is covered by this patch.
  2nd issue is covered by this FR.
https://bugs.php.net/bug.php?id=69908
 
  So it brings something for us :)
 Then what about strlen(number)?  are you also going to change its ZPP
 to accept zval instead of string?


 No. Only some kind of conversion functions are the subject.
 e.g. mb_convert_encoding(), mb_convert_kana(), etc.
What I meant is that it's rarely usage(like strlen(number)). we should
not care about them too much and break arg info.

and for the age usage you replied in github, I think the author of
such codes should be aware, if it's only number, then  instead of
htmlespcicalchars($age),  he should use echo $age directly... which is
more faster.

so, I am -1 or this optimization.

thanks

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Segfault in master with PHPUnit

[Xinchen Hui]

Hey Bob:

On Sun, Jun 14, 2015 at 2:08 PM, Sebastian Bergmann sebast...@php.net wrote:
 Am 14.06.2015 um 07:55 schrieb Xinchen Hui:
 maybe related to this : 3cfa58367b1b85d346d9be6cf9ae116c63571247

  Yes, reverting that commit fixes it. Thanks for the pointer!

please have a look of it.. I'd like revert it for now..

commit it again when it is fixed... ?

thanks


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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Segfault in master with PHPUnit

[Xinchen Hui]

Hey:

On Sun, Jun 14, 2015 at 1:42 PM, Sebastian Bergmann sebast...@php.net wrote:
 Am 14.06.2015 um 07:29 schrieb Sebastian Bergmann:
 I have run across a weird segfault with the current master when trying
 to run PHPUnit (using PHPUnit's own test suite). Weird because I get a
 segfault immediately on startup with a release build and a segfault much
 later when using a debug build. Detailed information is below, let me
 know if there is any additional information I should provide.

  Forgot to mention that I get no segfault with Alpha 1.

maybe related to this : 3cfa58367b1b85d346d9be6cf9ae116c63571247

could you please try again with revert that?

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] PR #1325 - array_column() for array of objects

[Xinchen Hui]

Hey:

On Fri, Jun 12, 2015 at 9:31 AM, Tjerk Meesters
tjerk.meest...@gmail.com wrote:
 Hi,

 I've created a PR here: https://github.com/php/php-src/pull/1325

 This enhancement allows for properties on objects to work in the same way
 as arrays for the inner elements of the main array.

IMO, it is called (array)_column...

and if you really want do it against object, you can always easily
convert the object to array.

thanks
 It also supports the __get() method, provided that also __isset() is
 implemented and returns true for the addressed property.

 The only BC I can imagine is when an array is populated with a mixed set of
 objects and arrays; any professional would baulk at the idea, but rules of
 the jungle are pervasive.

 Before I merge this, are there any objections to shipping this with 7.0?



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Bug #69180: Reflection does not honor trait conflict resolution / method aliasing

[Xinchen Hui]

Hey:

On Fri, May 29, 2015 at 5:21 PM, Sebastian Bergmann sebast...@php.net wrote:
 On 05/29/2015 08:59 AM, Xinchen Hui wrote:
 Actually, I had looked it, but there is no such Infos can be
 used after compiling is done in current traits design, so

  But calling C::bar() works, so PHP knows that there is a method named
  bar. Yet the Reflection API says that two methods named foo exist.
yeah, PHP knows, but only in lowercase 

it's not the right thing we need..

thanks


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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Bug #69180: Reflection does not honor trait conflict resolution / method aliasing

[Xinchen Hui]

Hey：
 

Sent from my iPhone

 On May 29, 2015, at 1:57 PM, Sebastian Bergmann sebast...@php.net wrote:
 
 Would be nice if somebody could have a look at
 https://bugs.php.net/bug.php?id=69180 -- thanks!
Actually, I had looked it, but there is no such Infos can be used after 
compiling is done in current traits design, so

Sorry I don't remember why I didn't reply in the bug entry

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

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

Re: [PHP-DEV] Pull request labels handling

[Xinchen Hui]

On Wed, May 27, 2015 at 10:27 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
 On Wed, May 27, 2015 at 6:29 AM, Anatol Belski anatol@belski.net wrote:
 Hi,

 the PRs on github are already being labeled. Multiple labels are possible.
 However the github ACLs lack on granularity
 https://help.github.com/articles/permission-levels-for-an-organization-repos
 itory/ . Due to that, while being a useful feature, labeling is only
 available for project admins or alike. Now with PHP7 such labeling becomes
 probably even more sense as we'll need to handle BC breaks and other
 situations which would need more testing and care. So the amount of work to
 evaluate and review PRs will grow while the work team probably not.


 I don't have time to work on qa.php.net/pulls and add such feature, so
 I gave Xinchen and Nikita admin rights for the organization as a
 workaround. Stas was already an admin.

 We did mention that if labelling is supposed to be integral part of
 the workflow this must be available for the normal karma holder and
 therefore needs to be integrated somehow.
Github expose such apis already
https://developer.github.com/v3/issues/#edit-an-issue

so I think it's not very difficult to add such features to qa.php.net/pulls now.

any volunteer ?  if no, I can work on it this weekend... hope I didn't
forget my experience on jquery :)


thanks

 -Hannes

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

[Xinchen Hui]

Hey:

On Sat, May 16, 2015 at 1:41 AM, Dan Ackroyd dan...@basereality.com wrote:
 On 15 May 2015 at 17:12, Xinchen Hui larue...@gmail.com wrote:
 How would that work when people want to write unit/integration tests
 to test the behaviour of a module when an EngineException is thrown?

 If you can't create a certain type of exception, it would mean that
 some code is basically untestable...which seems bad.
 You can not creat it directly, but you can trigger the engine to throw one


 I don't think having to do something like:

 eval(?php echo bar(};);

 to test ParseExceptions is a good plan.

 Can you say what the actual problem is that would be solved by not
 allowing them to be initialized from userland? It seems an artificial
 limitation that just makes it harder to test programs.
EngineException/TypeException/ParserException is designed for internal
errors only.

if then are used in user land. they may cause lots of side affects,
this bug is one of them...

thanks

 cheers
 Dan



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

[Xinchen Hui]

Hey：

 On May 16, 2015, at 12:35 AM, Dan Ackroyd dan...@basereality.com wrote:
 
 On 15 May 2015 at 14:38, Xinchen Hui larue...@gmail.com wrote:
 Hey:
 
   as described in https://bugs.php.net/bug.php?id=69640thanks=1
 
   instead of fixing it by exam the error type,  I'd prefer to
 disallow initializing a engine exception from user land..
 
 
 How would that work when people want to write unit/integration tests
 to test the behaviour of a module when an EngineException is thrown?
 
 If you can't create a certain type of exception, it would mean that
 some code is basically untestable...which seems bad.
You can not creat it directly, but you can trigger the engine to throw one

Thanks
 
 cheers
 Dan

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

Re: [PHP-DEV] Fixing bundled extension version mess

[Xinchen Hui]

Hey：

Sent from my iPhone

 On Apr 15, 2015, at 10:21 AM, Pierre Joye pierre@gmail.com wrote:
 
 hi,
 
 We tried that many times but we fail to handle the version of bundled
 extensions.
 
 Along with some installer work and other integration (projects
 dependencies management, composer or other), we need to find a way to
 get rid of this problem.
 
 What do you think to simply use the PHP version number instead of some
 outdated (most of the time) version for all bundled extensions?
in generally, I am +1 on this

I was also thinking of this yesterday, but the problem with opcache is:

We already release pecl opcache with version 7.0.X

If we now use Php version instead, then use may be confused with the versions?

Anyway,  I still +1 on this

Thanks
 For extensions being available both bundled or externally, the
 external versions will provide a sane version number when installed
 (like timezone db or other).
 
 Doing so will make requirements management much easier by adding a
 list of core extensions per PHP version.
 
 Thoughts?
 
 Cheers,
 -- 
 Pierre
 
 @pierrejoye | http://www.libgd.org
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

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

Re: [PHP-DEV] is_callable and function_exists with disable_functions

[Xinchen Hui]

Hey:



On Fri, Mar 27, 2015 at 1:14 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi all,

 On Fri, Mar 27, 2015 at 11:57 AM, Xinchen Hui larue...@php.net wrote:

 On Fri, Mar 27, 2015 at 3:06 AM, Kalle Sommer Nielsen ka...@php.net
 wrote:
  Forgot to CC list
 
 
  -- Forwarded message --
  From: Kalle Sommer Nielsen ka...@php.net
  Date: 2015-03-26 20:06 GMT+01:00
  Subject: Re: [PHP-DEV] is_callable and function_exists with
  disable_functions
  To: Remi Collet r...@fedoraproject.org
 
 
  2015-03-26 16:32 GMT+01:00 Remi Collet r...@fedoraproject.org:
  do you mind if I change the current behavior of is_callable , to
  return false on this case?
 
  Make sense
 
  or, at least, change function_exists's behavior instead?
 
  Seems a bad idea.
 
  I agree with both points here, I think is_callable() should mimic
  function_exists() behavior, is this the same case for disable_classes?
 
 yeah. but a little bit different

 class_exists return trun with disabled classes :

 $ sapi/cli/php -d disable_classes=ArrayObject -r
 var_dump(class_exists('arrayobject')); new ArrayObject(); 
 bool(true)
 PHP Warning:  ArrayObject() has been disabled for security reasons in
 Command line code on line 1

 Warning: ArrayObject() has been disabled for security reasons in
 Command line code on line 1


 Returning true for is_callable/class_exists even when it isn't usable does
 not make much sense. How about fix them all?

I filed a bug here: https://bugs.php.net/bug.php?id=69315thanks=4

will make a fix soon

thanks

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

[Xinchen Hui]

Hey:

On Fri, Mar 27, 2015 at 1:10 PM, Kris Craig kris.cr...@gmail.com wrote:
 On Thu, Mar 26, 2015 at 3:40 PM, Alain Williams a...@phcomp.co.uk wrote:

 On Thu, Mar 26, 2015 at 10:31:00PM +, Rowan Collins wrote:

  What I've always been annoyed by is the *precedence* of the operator -
 having to add brackets to mix it with string concatenation, etc - which it
 turns out to is the same in all sorts of languages.

 It is the ''all sorts of languages'' that is key here. The point is that
 PHP
 associativity for ?: is different from other languages and it is that that
 confuses and leads to bugs. What is right/wrong is not as important as all
 others doing it the other way.

 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information:
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h

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


 The feature freeze thing kinda rings hollow for me, as well, because we
 were debating this fairly recently before the feature freeze and we still
 got pushback from people who feared BC breakage.  This is a bug (whether
 we're calling it one or not, it is a bug) and it needs to be fixed.  PHP
 does handle it differently, yes, but the different way in which it's
 handling it is wrong.  At least, that seems to be the prevailing opinion
 among devs.

 If we don't put this in 7.0 because of the feature freeze, it needs to go
 into the next minor version if the RFC passes.  We should've pulled the
 trigger on this before the feature freeze and we shouldn't have to wait
 until 8.0 because of that.

I don't think freeze should block bug fixes...

thanks
 --Kris



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] is_callable and function_exists with disable_functions

[Xinchen Hui]

Hey:

On Fri, Mar 27, 2015 at 5:02 PM, Dmitry Stogov dmi...@zend.com wrote:
 Unfortunately this id not so simple :(

 If we change class_exists() the following code will stop working

 ?php
 if (!class_exists(SomeInternalClass)) {
   class SomeInternalClass {}
 }
 ?

 On the other hand function_exists() already behaves differently. (so
 function_exists() and class_exists() are inconsistent) :(
 Changing is_callable() semantic may be dangerous as well.
 What is we disable strcmp() and then pass is as a callback to usort()?

too bad :

 I wouldn't make any changes in hurry. this should be discussed and analysed
 carefully.

 However preventing conversion of disabled functions into opcodes and their
 optimization makes full sense.

okey, I will separate these part to a single fix

thanks
 Thanks. Dmitry.



 On Fri, Mar 27, 2015 at 9:41 AM, Xinchen Hui larue...@php.net wrote:

 Hey:



 On Fri, Mar 27, 2015 at 1:14 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
  Hi all,
 
  On Fri, Mar 27, 2015 at 11:57 AM, Xinchen Hui larue...@php.net wrote:
 
  On Fri, Mar 27, 2015 at 3:06 AM, Kalle Sommer Nielsen ka...@php.net
  wrote:
   Forgot to CC list
  
  
   -- Forwarded message --
   From: Kalle Sommer Nielsen ka...@php.net
   Date: 2015-03-26 20:06 GMT+01:00
   Subject: Re: [PHP-DEV] is_callable and function_exists with
   disable_functions
   To: Remi Collet r...@fedoraproject.org
  
  
   2015-03-26 16:32 GMT+01:00 Remi Collet r...@fedoraproject.org:
   do you mind if I change the current behavior of is_callable , to
   return false on this case?
  
   Make sense
  
   or, at least, change function_exists's behavior instead?
  
   Seems a bad idea.
  
   I agree with both points here, I think is_callable() should mimic
   function_exists() behavior, is this the same case for
   disable_classes?
  
  yeah. but a little bit different
 
  class_exists return trun with disabled classes :
 
  $ sapi/cli/php -d disable_classes=ArrayObject -r
  var_dump(class_exists('arrayobject')); new ArrayObject(); 
  bool(true)
  PHP Warning:  ArrayObject() has been disabled for security reasons in
  Command line code on line 1
 
  Warning: ArrayObject() has been disabled for security reasons in
  Command line code on line 1
 
 
  Returning true for is_callable/class_exists even when it isn't usable
  does
  not make much sense. How about fix them all?

 I filed a bug here: https://bugs.php.net/bug.php?id=69315thanks=4

 will make a fix soon

 thanks
 
  Regards,
 
  --
  Yasuo Ohgaki
  yohg...@ohgaki.net
 



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/

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





-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] is_callable and function_exists with disable_functions

[Xinchen Hui]

Hey Internal:

there is one confused behavior with disable_functions:

 $ sapi/cli/php -n -d disable_functions=strlen -r
'var_dump(function_exists(strlen));
var_dump(is_callable(strlen));'
bool(false)
bool(true)

  as you can see,  strlen is disabled by disable_functions.

  function_exisis tell it is not exists but is_callable said it is
callable..

  do you mind if I change the current behavior of is_callable , to
return false on this case?

  or, at least, change function_exists's behavior instead?

   thanks

-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] Re: Use ropes for string concatenation

[Xinchen Hui]

Hey:

On Tue, Mar 24, 2015 at 5:28 PM, Xinchen Hui larue...@gmail.com wrote:
 Hey

 Sent from my iPhone

 On Mar 24, 2015, at 5:11 PM, Nikita Popov nikita@gmail.com wrote:

 On Mon, Mar 23, 2015 at 11:41 PM, Dmitry Stogov dmi...@zend.com wrote:

 Hi,

 Recently, Xinchen and me worked on optimization that eliminates useless
 reallocations and copying during string concatenation (ZEND_ADD_STRING and
 family + ZEND_CONCAT).

 The idea comes from ropes, but adopted especially for our needs.
 Rope is popular data structure in languages with immutable strings.
 http://en.wikipedia.org/wiki/Rope_%28data_structure%29

 We don't try to use ropes everywhere in the engine (at least it's too
 later for 7.0), only for concatenation.

 The first branch uses ropes only instead of ZEND_ADD_STRING and family.
 This must be safe. The only problem is possible memory leaks on exception
 (but we already have this problem anyway). The simplest way to understand
 the patch - read code for new opcodes in zend_vm_def.h.

 https://github.com/php/php-src/pull/1194/files

 The second branch in addition uses ropes for series of ZEND_CONCAT. It
 disables calls to do_operation(ZEND_CONCAT) handler of custom internal
 classes.

 https://github.com/php/php-src/pull/1195/files

 Both make slight speed improvement (first +0.3%, second +0.6% on wordpress
 home page).

 We don't currently use ability to override CONCAT behavior in internal
 classes, and I'm not sure if it may be useful at all. (For example Lua
 doesn't provide concat meta-method). May be remove it?


 Overloading concat operator will be useful in the future for the
 implementation of the UString class, for example.

 then we can implement is in rope_end handler, and don't convert op to string
 in rope add var handler.
Never mind, lets stict to the first banch instead.

thanks for reviewing,  :)

thanks

 Thanks

 Nikita



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] Re: Use ropes for string concatenation

[Xinchen Hui]

Hey

Sent from my iPhone

 On Mar 24, 2015, at 5:11 PM, Nikita Popov nikita@gmail.com wrote:
 
 On Mon, Mar 23, 2015 at 11:41 PM, Dmitry Stogov dmi...@zend.com wrote:
 Hi,
 
 Recently, Xinchen and me worked on optimization that eliminates useless 
 reallocations and copying during string concatenation (ZEND_ADD_STRING and 
 family + ZEND_CONCAT).
 
 The idea comes from ropes, but adopted especially for our needs.
 Rope is popular data structure in languages with immutable strings.
 http://en.wikipedia.org/wiki/Rope_%28data_structure%29
 
 We don't try to use ropes everywhere in the engine (at least it's too later 
 for 7.0), only for concatenation.
 
 The first branch uses ropes only instead of ZEND_ADD_STRING and family. This 
 must be safe. The only problem is possible memory leaks on exception (but we 
 already have this problem anyway). The simplest way to understand the patch 
 - read code for new opcodes in zend_vm_def.h.
 
 https://github.com/php/php-src/pull/1194/files
 
 The second branch in addition uses ropes for series of ZEND_CONCAT. It 
 disables calls to do_operation(ZEND_CONCAT) handler of custom internal 
 classes.
 
 https://github.com/php/php-src/pull/1195/files
 
 Both make slight speed improvement (first +0.3%, second +0.6% on wordpress 
 home page).
 
 We don't currently use ability to override CONCAT behavior in internal 
 classes, and I'm not sure if it may be useful at all. (For example Lua 
 doesn't provide concat meta-method). May be remove it?
 
 Overloading concat operator will be useful in the future for the 
 implementation of the UString class, for example.
 
then we can implement is in rope_end handler, and don't convert op to string in 
rope add var handler.

Thanks
 Nikita

[PHP-DEV] Re: Use ropes for string concatenation

[Xinchen Hui]

Hey:

On Tue, Mar 24, 2015 at 7:51 PM, Nikita Popov nikita@gmail.com wrote:
 On Tue, Mar 24, 2015 at 10:28 AM, Dmitry Stogov dmi...@zend.com wrote:

 I thought about something like this :)
 In my opinion UString is really not a proper way to implement Unicoide,
 but I agree not break anything in current stage.
 Anyway, please review the first PR (in my opinion it is safe to commit),
 but you may find some other issues.

 Thanks. Dmitry.


 First PR looks okay to me. One question: Why the separate INIT and ADD
 opcodes? They seem pretty much the same, just one using a hardcoded 0
 instead of ex_val.

 Regarding exception-safety - is the problem that doing an EG(exception)
 check and releasing the rope is too expensive?
that won't work if :

?php
function a() {
throw  new exception($a);
return xxx;
}


try {
   $a = a ${a()} ;
} catch (Exception $a) {

}


thanks
thanks

 Nikita



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Use ropes for string concatenation

[Xinchen Hui]

Hey:

On Tue, Mar 24, 2015 at 2:04 PM, Pierre Joye pierre@gmail.com wrote:
 On Tue, Mar 24, 2015 at 1:01 PM, Xinchen Hui xinche...@zend.com wrote:
 Hey:

 On Tue, Mar 24, 2015 at 1:54 PM, Pierre Joye pierre@gmail.com wrote:
 On Tue, Mar 24, 2015 at 12:35 PM, Xinchen Hui xinche...@zend.com wrote:
 Hey:

 On Tue, Mar 24, 2015 at 1:31 PM, Pierre Joye pierre@gmail.com wrote:
 hi!

 On Tue, Mar 24, 2015 at 5:41 AM, Dmitry Stogov dmi...@zend.com wrote:
 Hi,

 Recently, Xinchen and me worked on optimization that eliminates useless
 reallocations and copying during string concatenation (ZEND_ADD_STRING 
 and
 family + ZEND_CONCAT).

 The idea comes from ropes, but adopted especially for our needs.
 Rope is popular data structure in languages with immutable strings.
 http://en.wikipedia.org/wiki/Rope_%28data_structure%29

 We don't try to use ropes everywhere in the engine (at least it's too 
 later
 for 7.0), only for concatenation.

 The first branch uses ropes only instead of ZEND_ADD_STRING and family.
 This must be safe. The only problem is possible memory leaks on exception
 (but we already have this problem anyway). The simplest way to understand
 the patch - read code for new opcodes in zend_vm_def.h.

 https://github.com/php/php-src/pull/1194/files

 The second branch in addition uses ropes for series of ZEND_CONCAT. It
 disables calls to do_operation(ZEND_CONCAT) handler of custom internal
 classes.

 https://github.com/php/php-src/pull/1195/files

 Both make slight speed improvement (first +0.3%, second +0.6% on 
 wordpress
 home page).

 We don't currently use ability to override CONCAT behavior in internal
 classes, and I'm not sure if it may be useful at all. (For example Lua
 doesn't provide concat meta-method). May be remove it?

 Thoughts and comments are welcome.

 Great work! :)

 Do you expect similar gain for other ops?

 I wonder if it would not be better to target 7.1 for that,  adding it
 for other string operations, in one go. Most of the current patch is
 self contained, it adds quite some complexity to the engine for these
 operations only and it is not a small change at this stage (post
 features freeze). It sounds like a possible maintenance pain. Taking
 Actually, it's not.

 previously we have ADD_STRING/CHAR/VAR and CONCAT

 the 2nd branch cleanup these, and now we only deal with one type 
 concat_list. :)

 Right, it simplifies part of the existing implementation and add some
 complexities to other. It only adds this OP and keep other with the
 old implementation, that's actually the only part where I am not
 totally convinced. It may make sense to do it all at once, if that's
 the long term plan, easier to maintain.

 But if we do prefer to add this now, then the sooner the better, it
 may have some hard to catch bugs. Now, we have one issue, we cannot
 have a RFC (deadline behind us) and this is still a rather big change
 :/
 from user land.  this won't change anything..

 Nothing to do with userland or not but code stabilization
In that case, yeah. you might be right.

but from my opinion, simpler always means easier for maintaining

anyway, I hope this could be merged to 7.0(the second branch) :)

thanks

 and regarding to the object overriden concat.

 I doubt it is not used at all :)

 --
 Pierre

 @pierrejoye | http://www.libgd.org



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Use ropes for string concatenation

[Xinchen Hui]

Hey:

On Tue, Mar 24, 2015 at 1:54 PM, Pierre Joye pierre@gmail.com wrote:
 On Tue, Mar 24, 2015 at 12:35 PM, Xinchen Hui xinche...@zend.com wrote:
 Hey:

 On Tue, Mar 24, 2015 at 1:31 PM, Pierre Joye pierre@gmail.com wrote:
 hi!

 On Tue, Mar 24, 2015 at 5:41 AM, Dmitry Stogov dmi...@zend.com wrote:
 Hi,

 Recently, Xinchen and me worked on optimization that eliminates useless
 reallocations and copying during string concatenation (ZEND_ADD_STRING and
 family + ZEND_CONCAT).

 The idea comes from ropes, but adopted especially for our needs.
 Rope is popular data structure in languages with immutable strings.
 http://en.wikipedia.org/wiki/Rope_%28data_structure%29

 We don't try to use ropes everywhere in the engine (at least it's too later
 for 7.0), only for concatenation.

 The first branch uses ropes only instead of ZEND_ADD_STRING and family.
 This must be safe. The only problem is possible memory leaks on exception
 (but we already have this problem anyway). The simplest way to understand
 the patch - read code for new opcodes in zend_vm_def.h.

 https://github.com/php/php-src/pull/1194/files

 The second branch in addition uses ropes for series of ZEND_CONCAT. It
 disables calls to do_operation(ZEND_CONCAT) handler of custom internal
 classes.

 https://github.com/php/php-src/pull/1195/files

 Both make slight speed improvement (first +0.3%, second +0.6% on wordpress
 home page).

 We don't currently use ability to override CONCAT behavior in internal
 classes, and I'm not sure if it may be useful at all. (For example Lua
 doesn't provide concat meta-method). May be remove it?

 Thoughts and comments are welcome.

 Great work! :)

 Do you expect similar gain for other ops?

 I wonder if it would not be better to target 7.1 for that,  adding it
 for other string operations, in one go. Most of the current patch is
 self contained, it adds quite some complexity to the engine for these
 operations only and it is not a small change at this stage (post
 features freeze). It sounds like a possible maintenance pain. Taking
 Actually, it's not.

 previously we have ADD_STRING/CHAR/VAR and CONCAT

 the 2nd branch cleanup these, and now we only deal with one type 
 concat_list. :)

 Right, it simplifies part of the existing implementation and add some
 complexities to other. It only adds this OP and keep other with the
 old implementation, that's actually the only part where I am not
 totally convinced. It may make sense to do it all at once, if that's
 the long term plan, easier to maintain.

 But if we do prefer to add this now, then the sooner the better, it
 may have some hard to catch bugs. Now, we have one issue, we cannot
 have a RFC (deadline behind us) and this is still a rather big change
 :/
from user land.  this won't change anything..

and regarding to the object overriden concat.

I doubt it is not used at all :)

thanks

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Use ropes for string concatenation

[Xinchen Hui]

Hey:

On Tue, Mar 24, 2015 at 1:31 PM, Pierre Joye pierre@gmail.com wrote:
 hi!

 On Tue, Mar 24, 2015 at 5:41 AM, Dmitry Stogov dmi...@zend.com wrote:
 Hi,

 Recently, Xinchen and me worked on optimization that eliminates useless
 reallocations and copying during string concatenation (ZEND_ADD_STRING and
 family + ZEND_CONCAT).

 The idea comes from ropes, but adopted especially for our needs.
 Rope is popular data structure in languages with immutable strings.
 http://en.wikipedia.org/wiki/Rope_%28data_structure%29

 We don't try to use ropes everywhere in the engine (at least it's too later
 for 7.0), only for concatenation.

 The first branch uses ropes only instead of ZEND_ADD_STRING and family.
 This must be safe. The only problem is possible memory leaks on exception
 (but we already have this problem anyway). The simplest way to understand
 the patch - read code for new opcodes in zend_vm_def.h.

 https://github.com/php/php-src/pull/1194/files

 The second branch in addition uses ropes for series of ZEND_CONCAT. It
 disables calls to do_operation(ZEND_CONCAT) handler of custom internal
 classes.

 https://github.com/php/php-src/pull/1195/files

 Both make slight speed improvement (first +0.3%, second +0.6% on wordpress
 home page).

 We don't currently use ability to override CONCAT behavior in internal
 classes, and I'm not sure if it may be useful at all. (For example Lua
 doesn't provide concat meta-method). May be remove it?

 Thoughts and comments are welcome.

 Great work! :)

 Do you expect similar gain for other ops?

 I wonder if it would not be better to target 7.1 for that,  adding it
 for other string operations, in one go. Most of the current patch is
 self contained, it adds quite some complexity to the engine for these
 operations only and it is not a small change at this stage (post
 features freeze). It sounds like a possible maintenance pain. Taking
Actually, it's not.

previously we have ADD_STRING/CHAR/VAR and CONCAT

the 2nd branch cleanup these, and now we only deal with one type concat_list. :)

thanks

 more time to actually experiment and implement this idea sounds safer
 to me (read: we have a bit less than a year to valid it then).

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

[Xinchen Hui]

Hey:

On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui larue...@php.net wrote:
 Hey:

 On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams a...@phcomp.co.uk wrote:
 On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote:
 On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
  Hi internals,
  Hi internals,
 
  The RFC to add a user-land function for an easy-to-use and reliable
  preg_replace_callback_array() in PHP is up for discussion:
  https://wiki.php.net/rfc/preg_replace_callback_array
 
  This proposes adding one function: `preg_replace_callback_array()` that
  is the better way to Implement when there are multiple patterns need to
  replace.
 
  I would love to hear your feedback! :)
  Any objections?
 
  I’ve sent this mail for four days, I don’t know if this RFC needs a vote.
  If you guys have no objections on this, please review the code and merge 
  it,
  thanks.

 Nice job, i like the idea.

 I am not sure about a RFC or not. It somehow looks like a sane
 replacement for something we killed (with good reasons).

 Let see what the other think :)

 I used s/something/code/ge in a perl script that I wrote a few days ago. Very
 useful. It would have been a lot more work to do it another way.

 So: +1 to the ability to do this, regardless of what mechanism is eventually 
 chosen.

 I also +1 for this.

 if there is no objections raises, I am going to merge it tomorrow..
merged

thanks

 thanks

 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information: 
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h

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



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

[Xinchen Hui]

Hey:

On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams a...@phcomp.co.uk wrote:
 On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote:
 On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
  Hi internals,
  Hi internals,
 
  The RFC to add a user-land function for an easy-to-use and reliable
  preg_replace_callback_array() in PHP is up for discussion:
  https://wiki.php.net/rfc/preg_replace_callback_array
 
  This proposes adding one function: `preg_replace_callback_array()` that
  is the better way to Implement when there are multiple patterns need to
  replace.
 
  I would love to hear your feedback! :)
  Any objections?
 
  I’ve sent this mail for four days, I don’t know if this RFC needs a vote.
  If you guys have no objections on this, please review the code and merge 
  it,
  thanks.

 Nice job, i like the idea.

 I am not sure about a RFC or not. It somehow looks like a sane
 replacement for something we killed (with good reasons).

 Let see what the other think :)

 I used s/something/code/ge in a perl script that I wrote a few days ago. Very
 useful. It would have been a lot more work to do it another way.

 So: +1 to the ability to do this, regardless of what mechanism is eventually 
 chosen.

I also +1 for this.

if there is no objections raises, I am going to merge it tomorrow..

thanks

 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information: 
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Xinchen Hui]

On Tue, Mar 17, 2015 at 9:45 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Anthony,

 On Tue, Mar 17, 2015 at 6:03 AM, Anthony Ferrara ircmax...@gmail.com
 wrote:

 Voting has been closed on the scalar type declarations v0.5 RFC:

 https://wiki.php.net/rfc/scalar_type_hints_v5

 At a final score of 108:48, it has been accepted for PHP 7.


 Congratulations. Even though I dislike stirct_types part, I appreciate
 your efforts.
Same here.

anyway, I think there is no time doing any changes on this.

Let's wait and see, how the community use this strict_types..

anyway,  I am glad this thread is finally done.

thanks

 Since weakly typed mode is too weak to be useful for detecting possible
 errors and
 strict type mode is overridden by any caller(parent script), it's still
 reasonable to have
 CoerciveSTH RFC. I hope many of us see the benefits of the RFC also.

 BTW, I suggest to remove the word strict from strict_types at least as
 it is
 not strict at all if caller(parent script) does not specify
 strict_types=1.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 9:32 PM, Pascal Chevrel pascal.chev...@free.fr wrote:
 Le 16/03/2015 12:39, Xinchen Hui a écrit :

 Hey:



 And last comment,  if there no such declare thing, I will definitely
 vote yes to this RFC.


 Hi Xinchen,

 You can also not vote at all, that's a very valid option.
 By voting yes, you say that you want PHP developers to have access to STH in
 PHP 7, by voting No, you say that you don't want PHP developers to be able
 to use STH in PHP 7. By not voting, you let the rest of the PHP community
 that cares about STH (both for and against) decide if the feature gets in
 the language. As a person with voting rights, you should study the RFCs in
 details, understand them fully and vote on what you think you have
 understanding and expertise on. There is no obligation to vote on all RFCs.

 It seems that you won't use STH yourself so you will probably never use
 declare in your code and won't be impacted by the existence or not of the
 feature. I also don't like how the declare syntax looks, and similarily I
 personnally dislike even more how ugly the namespace syntax is in PHP with
 the backslashes (Foo\Bar\Baz), yet, I am happy that we do have the
 possibility to namespace our code, because PHP 5 *needed* that feature. And
 I think PHP 7 needs something like that, I also think it's a very clever
 solution as we can keep on using PHP as a weakly typed language as usual but
 also strenghten some of our code that needs strong typing.


 that's why I want vote no for this, and wait for Bob's  Basic STH.

 thanks


 It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
 proposed way too late and the coercive STH RFC has just zero chance to pass,
 it's too much of a BC break for everybody. The dual mode STH is the only
 chance to have something for PHP 7 and remain competitive with HHVM,
 Node.js… that we see people switch to. Baidu switched to HHVM, Wikipedia
 too, in my country big names switched from PHP to node.js and that was not
 just for performance reasons, it was also for the features. Zeev himself
 admitted that we need something for PHP 7.

 Personnally, I think the dual mode is a very clever way to please all PHP
 developpers, those that want to use weak typing, those that want to use
 stronger typing and those like me that would continue to use weak typing
 because it's convenient but would be happy to use STH on very specific parts
 of his code that would benefit from it.
don't worry,  it will pass

thanks

 Cheers,

 Pascal



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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Dual Mode STH

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 10:21 PM, Zeev Suraski z...@zend.com wrote:
 All,



 After much thinking, and despite grave concerns I raised about what
 transpired in the last 24 hours, I decided to get behind the Dual Mode RFC
 at this time.



 I call upon everyone - both people that haven’t yet voted and those who
 voted no - to do the same so that we ensure that we have STH in PHP 7.0:

 wiki.php.net/rfc/scalar_type_hints_v5#vote



 As I’ve said all along, I’m not doing it because I think it’s good, I
 actually think it’s pretty bad – both in absolute terms and in the
 precedent for introducing ‘both’ options instead of a single opinionated
 one.  That move is designed to help ensure that we have SOME form of Scalar
 Type Hints in PHP 7.0, which is clearly what the userbase at large wants.
 We can revisit casting rules in the future without time pressure, and in
 general, see how this new feature is accepted and used.



 Again,  I call upon everybody to vote Yes for the Dual Mode RFC to ensure
 that we have some form of STH in PHP 7.0.
Unecessary for everybody, one or two change from no to yes will make it pass. :)

thanks



 Zeev



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

Hey:



On Mon, Mar 16, 2015 at 7:33 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Derick,

 On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:

 On Mon, 16 Mar 2015, Xinchen Hui wrote:

  On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com
  wrote:
  
   On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
  
that means, I need to add a lots of (int) while I try to call a
   function in a library which is not written by myself.
  
is that right?
  
   You got the answer but one thing bothers me a lot right now.
  
   How did you vote against this rfc while missing the core point of it
   (after
   actually having a strict mode)?

  as I said,
  
   acutaly, I believe in most applications, they will still keep this
  off..
 
so why we introduce such thing?
  
  I don't like strict_types at all..

 To be frank, I don't think I don't like this is a terribly good reason
 to vote against (or for something). What is important is how many people
 would actually benefit from a feature, without it causing issues for
 others. I am certainly no fan of the declare *syntax*, but I do know,
 from talking at conferences that many many developers would like to see
 scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
 strict (mode 2). It even caters for people that don't want to use them
 at all, as they can simply not use them. I also know, that without a
 dual mode, it seems very unlikely for scalar type hints to make it
 into PHP 7, and I don't think that is what users want. As this is our
 *best* bet, I can only vote yes.


 Are you sure on your bet?

 lib.php:
 ?php
 declare(strict_types = 1);
 function foo(int $a) {
 // no function call here
 }
 ?
 The declare here does just nothing.

 a.php:
 ?php
 require lib.php;
 foo(123); // will work
 ?

 b.php:
 ?php
 declare(strict_types = 1);
 require lib.php;
 foo(123); // will give an error
 ?

 This behavior is unacceptable.
 Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
 work as it should. Otherwise, all kinds of unexpected for lib.php and it's
 users may happen.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

And last comment,  if there no such declare thing, I will definitely
vote yes to this RFC.

that's why I want vote no for this, and wait for Bob's  Basic STH.

thanks




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 7:18 PM, Derick Rethans der...@php.net wrote:
 On Mon, 16 Mar 2015, Xinchen Hui wrote:

 On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com wrote:
 
  On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
 
   that means, I need to add a lots of (int) while I try to call a
  function in a library which is not written by myself.
 
   is that right?
 
  You got the answer but one thing bothers me a lot right now.
 
  How did you vote against this rfc while missing the core point of it (after
  actually having a strict mode)?

 as I said,
 
  acutaly, I believe in most applications, they will still keep this off..

   so why we introduce such thing?
 
 I don't like strict_types at all..

 To be frank, I don't think I don't like this is a terribly good reason
 to vote against (or for something). What is important is how many people
 would actually benefit from a feature, without it causing issues for
 others. I am certainly no fan of the declare *syntax*, but I do know,
 from talking at conferences that many many developers would like to see
 scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
I think they just want a weak type hintings(PHP is a weak type
language).. not strict types.

especially not a dual mode,  switch on/off by a declare line..

it looks so ugly to me..

 strict (mode 2). It even caters for people that don't want to use them
 at all, as they can simply not use them. I also know, that without a
 dual mode, it seems very unlikely for scalar type hints to make it
 into PHP 7, and I don't think that is what users want. As this is our
 *best* bet, I can only vote yes.
I understand your choice,  but for me, as a six year PHP user. I can
see how strict types can benifit me..

the only usage I can image is,  turn on it in developer env to clean
types passing, and turn off in produce env for safety(in case I forget
to cast some types from $_GET $_POST).

which is definitlely can be done by a extension, or hook..

thanks

 cheers,
 Derick



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

On Mon, Mar 16, 2015 at 7:32 PM, Xinchen Hui larue...@php.net wrote:
 Hey:

 On Mon, Mar 16, 2015 at 7:18 PM, Derick Rethans der...@php.net wrote:
 On Mon, 16 Mar 2015, Xinchen Hui wrote:

 On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com wrote:
 
  On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
 
   that means, I need to add a lots of (int) while I try to call a
  function in a library which is not written by myself.
 
   is that right?
 
  You got the answer but one thing bothers me a lot right now.
 
  How did you vote against this rfc while missing the core point of it 
  (after
  actually having a strict mode)?

 as I said,
 
  acutaly, I believe in most applications, they will still keep this off..

   so why we introduce such thing?
 
 I don't like strict_types at all..

 To be frank, I don't think I don't like this is a terribly good reason
 to vote against (or for something). What is important is how many people
 would actually benefit from a feature, without it causing issues for
 others. I am certainly no fan of the declare *syntax*, but I do know,
 from talking at conferences that many many developers would like to see
 scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
 I think they just want a weak type hintings(PHP is a weak type
 language).. not strict types.

 especially not a dual mode,  switch on/off by a declare line..

 it looks so ugly to me..

 strict (mode 2). It even caters for people that don't want to use them
 at all, as they can simply not use them. I also know, that without a
 dual mode, it seems very unlikely for scalar type hints to make it
 into PHP 7, and I don't think that is what users want. As this is our
 *best* bet, I can only vote yes.
 I understand your choice,  but for me, as a six year PHP user. I can
 see how strict types can benifit me..
can not

 the only usage I can image is,  turn on it in developer env to clean
 types passing, and turn off in produce env for safety(in case I forget
 to cast some types from $_GET $_POST).

 which is definitlely can be done by a extension, or hook..

 thanks

 cheers,
 Derick



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com wrote:
 On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote:

 Hi internals,

 The RFC to add a user-land function for an easy-to-use and reliable
 preg_replace_callback_array() in PHP is up for discussion:
 https://wiki.php.net/rfc/preg_replace_callback_array

 This proposes adding one function: `preg_replace_callback_array()` that
 is the better way to Implement when there are multiple patterns need to
 replace.

 I would love to hear your feedback! :)


 Could you add a paragraph or two explaining the reasons for choosing this
 particular proposal?
 Some examples of what I would like to read:
  - why we can't do preg_replace_callback($array_of_regexes,
 $array_of_callbacks, $subject)
array() also could be a valid callback.. (array(clasname, methodname)).
  - why not preg_replace_callback($array_of_regex_to_callback_pairs,
 $subject)
there are also $limit, $count argument could be used.
  - why not pass the regex used to the callback, as per Laruence's earlier
 RFC
bc break..(change the callback's signature)

 And give a few links to historical discussions in the same sort of area?
 E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and
 its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq).

thanks



 Any objections?


 —
 Best,
 Wei Dai





-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 11:32 PM, Peter Cowburn petercowb...@gmail.com wrote:
 On 16 March 2015 at 14:59, Xinchen Hui larue...@php.net wrote:

 Hey:

 On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn petercowb...@gmail.com
 wrote:
  On 16 March 2015 at 01:40, Wei Dai zxcvda...@gmail.com wrote:
 
  Hi internals,
 
  The RFC to add a user-land function for an easy-to-use and reliable
  preg_replace_callback_array() in PHP is up for discussion:
  https://wiki.php.net/rfc/preg_replace_callback_array
 
  This proposes adding one function: `preg_replace_callback_array()` that
  is the better way to Implement when there are multiple patterns need to
  replace.
 
  I would love to hear your feedback! :)
 
 
  Could you add a paragraph or two explaining the reasons for choosing this
  particular proposal?
  Some examples of what I would like to read:
   - why we can't do preg_replace_callback($array_of_regexes,
  $array_of_callbacks, $subject)
 array() also could be a valid callback.. (array(clasname, methodname)).
   - why not preg_replace_callback($array_of_regex_to_callback_pairs,
  $subject)
 there are also $limit, $count argument could be used.
   - why not pass the regex used to the callback, as per Laruence's earlier
  RFC
 bc break..(change the callback's signature)
 
  And give a few links to historical discussions in the same sort of area?
  E.g Laruence's RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback
 and
  its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq).
 
 thanks


 In case my earlier message wasn't clear, I was asking for the RFC itself to
 be padded out with those sorts of details. The reason being, many (most)
 people won't be already familiar with the surrounding discussions that have
 happened previously, or the reasons for the potentially strange-seeming
 design choices made in this RFC.
hmm, yeah, it's better to have these in the RFC.

I just replied in case Wei Dai is not familar with these reasons


thanks


 
 
 
  Any objections?
 
 
  —
  Best,
  Wei Dai
 
 



 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 9:40 AM, Wei Dai zxcvda...@gmail.com wrote:
 Hi internals,

 The RFC to add a user-land function for an easy-to-use and reliable
 preg_replace_callback_array() in PHP is up for discussion:
 https://wiki.php.net/rfc/preg_replace_callback_array

 This proposes adding one function: `preg_replace_callback_array()` that
 is the better way to Implement when there are multiple patterns need to
 replace.

 I would love to hear your feedback! :)
 Any objections?
I have no objections on this, since I proposed similar thing before..

I think this is a good addition after we removed /e

if you objections raise in couple days, I will merge this.

thanks


 —
 Best,
 Wei Dai




-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Minimum version of GCC required to build PHP

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 2:35 PM, Sebastian Bergmann sebast...@php.net wrote:
 Am 15.03.2015 um 16:36 schrieb Sebastian Bergmann:
 Over in Room 11, Michael just pointed out that this could be related
 to php_stdint.h.

  Okay, this does not seem to be related to the GCC version but rather
  to the fact that some int types etc. are not defined on/for my platform.
  If I use -Dintptr_t=long -Duintptr_t=ulong, for instance, then I can
  compile PHP (but not link it, but that's another issue).

what is the link problems?

thanks

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre@gmail.com wrote:
 Hi,

 On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:

 Hey:

  The most unaccept feature in current STH thing(v.5.0) is this.

  acutaly, I believe in most applications, they will still keep this
 off..

  so why we introduce such thing?

  beside this,  I have a question, which is not explained in the RFC:

  lib.php
  ?php
declare(strict_types = 1);
function add(int $a, int $b) {
}
  ?

  assuming lib.php is a thrid part library which I want to use it
 in my project.

  but I use whole weak types in my project..

  thus I simply call  add by:

  ?php

   add($_GET['a'], $_GET['b']); //recoverable error  since all
 input in _GET _POST is string by default

  ?

  that means, I need to add a lots of (int) while I try to call a
 function in a library which is not written by myself.

  is that right?

 You got the answer but one thing bothers me a lot right now.

 How did you vote against this rfc while missing the core point of it (after
 actually having a strict mode)?
as I said,

 acutaly, I believe in most applications, they will still keep this off..

  so why we introduce such thing?

I don't like strict_types at all..

the question I asked is just want  one of my concern is not ture, or
not oversight by others.

thanks


-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

Hey:

 The most unaccept feature in current STH thing(v.5.0) is this.

 acutaly, I believe in most applications, they will still keep this off..

 so why we introduce such thing?

 beside this,  I have a question, which is not explained in the RFC:

 lib.php
 ?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }
 ?

 assuming lib.php is a thrid part library which I want to use it
in my project.

 but I use whole weak types in my project..

 thus I simply call  add by:

 ?php

  add($_GET['a'], $_GET['b']); //recoverable error  since all
input in _GET _POST is string by default

 ?

 that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.

 is that right?



thanks

-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] About declare(strict_types = 1)

[Xinchen Hui]

Hey:

On Mon, Mar 16, 2015 at 1:49 PM, Dennis Birkholz den...@birkholz.biz wrote:
 Hello Xinchen,

 Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
  lib.php
  ?php
declare(strict_types = 1);
function add(int $a, int $b) {
}

  ?php
   add($_GET['a'], $_GET['b']);

  that means, I need to add a lots of (int) while I try to call a
 function in a library which is not written by myself.

 that is not right and has been discussed a thousand times over.
 The declare changes the rules only for function calls in the file it is
 declared in.

 so:
 lib.php:
 ?php
 declare(strict_types = 1);
 function foo(int $a) {
 // no function call here
 }
 ?
 The declare here does just nothing.

 ?php
 require lib.php;
 foo(123); // will work
 ?

 ?php
 declare(strict_types = 1);
 require lib.php;
 foo(123); // will give an error
 ?

 Very easy, explained a thousand times over. Bringing up the same false
 arguments up again and again does really not help the discussion.
That is why I don't see it before (thousand times, too long to read...
but not in RFC)

anyway, thanks for answering

then I have no further questions anymore.

thanks

 Greets
 Dennis





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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Drop Multiply VM kind support

[Xinchen Hui]

Hey:

On Sat, Mar 14, 2015 at 8:01 PM, Bob Weinand bobw...@hotmail.com wrote:
 Am 13.03.2015 um 05:01 schrieb Xinchen Hui larue...@php.net:

 Hey:

 We have CALL SWITCH GOTO vm kind supports for long time.

 And we use CALL for default.

 SWITCH GOTO seems useless now, and brings us some troubles while
 maintaining .

 And also could make some extension unable to work, like in phpdbg:

  PHPDBG_G(vmret) = execute_data-opline-handler(execute_data);


 So, maybe it's time for us to remove GOTO and SWITCH at all?

 thanks

 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/

 Not sure whether it's useless, I'm not exactly aware of the performance 
 differences.
 But we would have to add some proper build-time check for phpdbg whether 
 we're in CALL mode or not. [when you're using phpdbg on that machine, you 
 probably aren't in a high-performance production environment anyway.]

 (Like with a clean #error message etc.)

After the latest fix by Dmitry, there will be no need for that.

because, if in non CALL mode, phpdbg won't be able to built anymore.

thanks
 Bob



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] Re: Drop Multiply VM kind support

[Xinchen Hui]

Hey:

On Fri, Mar 13, 2015 at 3:50 PM, Dmitry Stogov dmi...@zend.com wrote:
 Hi Xinchen,

 I don't like to remove anything. I think GOTO may be made faster. It's just
 not very interesting to invest into it, because CALL is more suitable.

 execute_data-opline-handler(execute_data); won't work with CALL and global
 CPU registers s well :(
that exactly how the problem came to my :)

thanks

 Thanks. Dmitry.



 On Fri, Mar 13, 2015 at 7:01 AM, Xinchen Hui larue...@php.net wrote:

 Hey:

  We have CALL SWITCH GOTO vm kind supports for long time.

  And we use CALL for default.

  SWITCH GOTO seems useless now, and brings us some troubles while
 maintaining .

  And also could make some extension unable to work, like in phpdbg:

   PHPDBG_G(vmret) =
 execute_data-opline-handler(execute_data);


  So, maybe it's time for us to remove GOTO and SWITCH at all?

  thanks

 --
 Xinchen Hui
 @Laruence
 http://www.laruence.com/





-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

[PHP-DEV] Drop Multiply VM kind support

[Xinchen Hui]

Hey:

 We have CALL SWITCH GOTO vm kind supports for long time.

 And we use CALL for default.

 SWITCH GOTO seems useless now, and brings us some troubles while
maintaining .

 And also could make some extension unable to work, like in phpdbg:

  PHPDBG_G(vmret) = execute_data-opline-handler(execute_data);


 So, maybe it's time for us to remove GOTO and SWITCH at all?

 thanks

-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [Discussion] Deprecate function sizeof()

[Xinchen Hui]

Hey:

On Tue, Mar 10, 2015 at 10:07 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Hi Reeze,

 On Mon, Mar 9, 2015 at 12:56 PM, reeze re...@php.net wrote:

 It is a deprecated warning I won't break code I think.

 This could makes those project more maintainable (new PHP programmer could
 be easier to maintain the code without surprise), and it will be trivial to
 fix this. We could move things forward ;-)


 It's possible option for confusing APIs.
 If sizeof() is kept at least until PHP8 or PHP9, I'll vote yes for this.
We just removed all DEPRECATED functions...

then you want to brings new :

anyway, I'd prefer don't do it. especially with little gain.

thanks

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Arrays being generated with length and no content on master

[Xinchen Hui]

Hey：

 On Mar 7, 2015, at 1:23 PM, Juan Basso jrba...@gmail.com wrote:
 
 I was testing CakePHP framework with PHP 7 and some tests were failing.
 Digging into the issue I found that using compact in a certain way can
 cause PHP to create an array with length but no content inside.
 
 I reported and added some examples on how to reproduce on
 https://bugs.php.net/bug.php?id=69198
 
 I'm sending this email more to bring the attention that this can be a
 potential issue on the engine since other places can have the same issue or
 even non-internals extensions can generate this kind of weirdness. I wonder
 if doing this can cause some security issue.
 
 
Should be fixed now

Thanks
 Thanks,
 Juan Basso

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