Re: com php-src: Fix bug #68446 (bug with constant defaults and type hints): Zend/tests/class_constants_002.phpt Zend/zend_compile.c
Zend/zend_execute.c Zend/zend_vm_def.h Zend/zend_vm_execute.h
| From: | Dmitry Stogov | Date: | Tue, 25 Nov 2014 11:16:14 +0000 |
| Subject: | Re: com php-src: Fix bug #68446 (bug with constant defaults and type hints): Zend/tests/class_constants_002.phpt Zend/zend_compile.c Zend/zend_execute.c Zend/zend_vm_def.h Zend/zend_vm_execute.h |
||
| References: | 1 2 3 4 5 | Groups: | php.cvs |
| Request: | Send a blank email to php-cvs+get-83316@lists.php.net to get a copy of this message | ||
Hi Bob,
Thanks. Please revert it for master as well.
Once you find a good fix you may commit it into 5.6 and master again.
Otherwise we will get a mess.
If you like, I may try to look into the problem and try to fix it as well.
Thanks. Dmitry.
On Tue, Nov 25, 2014 at 2:03 PM, Bob Weinand <bobwei9@hotmail.com> wrote:
> Am 24.11.2014 um 13:12 schrieb Dmitry Stogov <dmitry@zend.com>:
>
> On Mon, Nov 24, 2014 at 2:04 PM, Bob Weinand <bobwei9@hotmail.com> wrote:
>
>> Hey Dmitry,
>>
>> My changes shouldn't break code which isn't already fragile.
>> class_constants_002.phpt is such an example.
>>
>
> This is definitely a break
>
> php-5.5 -n -r 'function foo($x=Foo::Bar){var_dump($x);} foo(10);'
> int(10)
>
> php-5.6 -n -r 'function foo($x=Foo::Bar){var_dump($x);} foo(10);'
>
> Fatal error: Class 'Foo' not found in Command line code on line 1
>
> In some framework code it'll trigger Foo autoloading where it didn't do it
> before.
>
>
> It's a behavior change, but it shouldn't break code. But I agree, that's
> bad for a micro release.
>
> Though, I could restore old behavior and just evaluate in case a constant
>> is passed _and_ there is an array/callable typehint. Would that be fine?
>> In this case there wouldn't be any BC break (only already fatal-ing code
>> working again).
>>
>
> This BC break is not the single problem in the patch, I actually noticed
> it because of slight performance degradation. Also, could you explain this
> change: allow_null is defined as zend_bool, but now it can be initialized
> with 1 or 2?
>
> @@ -1931,8 +1931,8 @@ void zend_do_receive_param(zend_uchar op, znode
> *varname, const znode *initializ
> if (class_type->u.constant.type == IS_ARRAY) {
> cur_arg_info->type_hint = IS_ARRAY;
> if (op == ZEND_RECV_INIT) {
> - if
> (Z_TYPE(initialization->u.constant) == IS_NULL ||
> (Z_TYPE(initialization->u.constant) == IS_CONSTANT &&
> !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL")) ||
> Z_TYPE(initialization->u.constant) == IS_CONSTANT_AST) {
> - cur_arg_info->allow_null =
> 1;
> + if
> (Z_TYPE(initialization->u.constant) == IS_NULL ||
> (Z_TYPE(initialization->u.constant) & IS_CONSTANT_TYPE_MASK) == IS_CONSTANT
> || (Z_TYPE(initialization->u.constant) & IS_CONSTANT_TYPE_MASK) ==
> IS_CONSTANT_AST) {
> + cur_arg_info->allow_null =
> (Z_TYPE(initialization->u.constant) != IS_NULL) + 1;
> } else if
> (Z_TYPE(initialization->u.constant) != IS_ARRAY) {
>
> zend_error_noreturn(E_COMPILE_ERROR, "Default value for parameters with
> array type hint can only be an array or NULL");
> }
>
> I would prefer, if you revert your patch, and then propose better solution
> (without BC break).
> you patch is not simple, and analyzing one fix on top of another is not
> going to be simple.
>
>
> I somehow did something better when reimplementing for master, there
> class_constants_002.phpt is still the same and passes. I just don't
> understand _why_... I wonder now if we should leave that bug in 5.6 (and
> revert it there) or try to fix it there too? I will revert it today
> (because of 5.6.4rc1) if I don't get another reply from you today. Maybe
> you're able to quickly get what the difference between 5.6 and master is
> there?
>
> Bob
>
> Thanks. Dmitry.
>
>
>>
>> Thanks,
>> Bob
>>
>> Am 24.11.2014 um 09:26 schrieb Dmitry Stogov <dmitry@zend.com>:
>>
>> Hi Bob,
>>
>> Please, send such changes for review before committing.
>>
>> It is not a trivial change and it breaks existing behavior
>> (Zend/tests/class_constants_002.phpt).
>> Default values don't have to be evaluated, if actual parameter was sent.
>> Your patch may affect existing code in unpredictable way (e.g. start fail
>> because of error or trigger __autoload()).
>> Please, revert it. Such changes can't be done in minor releases.
>> Probably, the bug may be fixed in another way.
>>
>> Thanks. Dmitry.
>>
>> On Sun, Nov 23, 2014 at 11:10 PM, Bob Weinand <bwoebi@php.net> wrote:
>>
>>> Commit: 5ef138b0c7c4e9532e205f45c18a72aa1d279c24
>>> Author: Bob Weinand <bobwei9@hotmail.com> Sun, 23 Nov 2014
>>> 21:09:31 +0100
>>> Parents: c8dd41554387e100a09811cad7f7032a291a79c2
>>> Branches: PHP-5.6
>>>
>>> Link:
>>>
>>> http://git.php.net/?p=php-src.git;a=commitdiff;h=5ef138b0c7c4e9532e205f45c18a72aa1d279c24
>>>
>>> Log:
>>> Fix bug #68446 (bug with constant defaults and type hints)
>>>
>>> Bugs:
>>> https://bugs.php.net/68446
>>>
>>> Changed paths:
>>> M Zend/tests/class_constants_002.phpt
>>> M Zend/zend_compile.c
>>> M Zend/zend_execute.c
>>> M Zend/zend_vm_def.h
>>> M Zend/zend_vm_execute.h
>>>
>>>
>>> --
>>> PHP CVS Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>>
>>
>
>