Bug #72598 [Com]: Reference is lost after array_slice()

Edit report at https://bugs.php.net/bug.php?id=72598&edit=1 ID: 72598 Comment by: dominikschilling+php at gmail dot com Reported by: dominikschilling+php at gmail dot com Summary: Reference is lost after array_slice() Status: Analyzed Type: Bug Package: Scripting Engine problem PHP Version: 7.1Git-2016-07-14 (Git) Block user comment: N Private report: N New Comment: I'm curious what the status of this bug is. I've added the scripts to 3v4l.org to compare the output of different PHP versions: Script from comment 1: https://3v4l.org/MCmnj, warning exists in 7.1.0alpha2 - 7.1.0beta1 Script from comment 2: https://3v4l.org/WECs1, 7.0.0 - 7.1.0beta1 produces only one warning, 5.3.0 - 5.6.24 has two Another (unrelated?) script: https://3v4l.org/fESuN#v530, I noticed this because I got the (valid) warning after upgrading to 7.0.9. Previous Comments: ------------------------------------------------------------------------ [2016-07-15 20:06:22] nikic@php.net @dmitry: This warning/behavior has been around since forever, I don't understand why we should change it now. call_user_func_array() can't create a reference into the array, so we can only do a by-reference pass if the element is already a reference. If there's no existing reference, the call will not work correctly. (If the by-reference passing does not actually matter, then one should not use by-reference passing...) ------------------------------------------------------------------------ [2016-07-15 08:47:28] dmitry@php.net The problem is not related to $this handling at all. Test script: --------------- <?php function ref(&$a) { var_dump($a); } $b = 1; $args = [&$b]; unset($b); for ($i = 0; $i < 2; $i++) { $a = array_slice($args, 0, 1); call_user_func_array('ref', $a); } ?> Expected result: ---------------- int(1) int(1) Actual result: -------------- int(1) PHP Warning: Parameter 1 to ref() expected to be a reference, value given in %s on line %d I think this warning doesn't make a lot of sense at all, or at least it shouldn't prevent execution of the called function. Fixing this is a new minor BC break. ------------------------------------------------------------------------ [2016-07-14 21:33:07] bwoebi@php.net Yes, it should already fail at the first iteration I think. Modification of $this means the content of the $this variable itself, not the object. I.e. $this must never become another object or scalar. @dmitry yeah, that's a workaround, but it's only a workaround for the bug… the bug needs to be fixed somehow though before 7.1.0. I don't find this broken behavior acceptable to be shipped in the release. ------------------------------------------------------------------------ [2016-07-14 20:45:45] dominikschilling+php at gmail dot com Thanks for link to the RFC. I think I'm missing the point why "re-assign $this" == "modification of $this" which is basically "$this = 'something'" vs. "$this->something = 'something'". For example the following script is still working and also a modification of $this, although it's another context: class C { public $b; function foo(){ $this->b = 'a'; } } $x = new C; $x->foo(); var_dump($x->b); // Prints a > That it needs two iterations is another bug in array_slice Does that now mean that it should already fail on the first iteration? ------------------------------------------------------------------------ [2016-07-14 19:57:01] dmitry@php.net PHP-7.1 doesn't allow modification of $this through references on purpose. See https://wiki.php.net/rfc/this_var#disable_ability_to_re-assign_this_indirectly_through_reference The simplest workaround is replacing $this with another variable. - do_action_ref_array( 'pre_get_posts', [ &$this ] ); + $obj = $this; + do_action_ref_array( 'pre_get_posts', [ &$obj ] ); ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72598 -- Edit this bug report at https://bugs.php.net/bug.php?id=72598&edit=1