Make call_uer_func_array() populate regular values to references, if possible

[dstogov]

Fixed bug #72598 (Reference is lost after array_slice()).

[nikic]

What about call_user_func_array() not going through SEND_ARRAY (e.g. in namespace)? I think this code doesn't handle it yet.

[dstogov]

Regular call_user_func_array() is changed in the same way.

[nikic]

Ah, sorry, I missed part of the patch. However, I don't think those implementations do the same thing wrt how the argument is fetched. E.g. call_user_func_array('func', $undefined) will throw a notice for $undefined, while the same in a namespace will not. Similarly for call_user_func_array('func', $array[$key]) in one case this will do a FETCH_DIM_R and in the other (effectively) a FETCH_DIM_W. (Unless I misremember how PREFER_REF handling works, which may well be...)

[dstogov]

You are right. Probably it's not very hard to fix this (using _W mode for IS_VAR/IS_CV arrays).

What do you think about this solution in general.
Is it better or worse than yours? (I don't have strong opinion).

[bwoebi]

The changes to the tests are quite what I expect. Travis reports a segfault for these tests though...

@nikic Right, but it will throw a type error or at least emit a warning+zpp failure for undefined instead here? [but yeah, should never emit a notice then]

[dstogov]

All mentioned problems should be fixed now.

[nikic]

@dstogov About this approach in general, I'm not totally sure. One the one hand, this is a "pragmatic" solution, in that it usually will do what you want. However, this will probably introduce a few gotchas. For example, it is very common that the arguments passed to call_user_func_array() actually come from somewhere else, e.g.

function doCall($args) {
    call_user_func_array($fnWithRefArgs, $args);
}

Currently, if $args is not correctly prepared with references, this will generate a warning. After this change, the call will be allowed, silently, but the passed arguments will stay the same due to the intermediate by-value pass of $args.

[nikic]

In any case, I don't have a strong opinion either way. I think it may be good to discuss what to do here on the mailing list, as this is a larger issue.

[dstogov]

@nikic After all, I would prefer your #2059
It breaks few tests, but I hope, it shouldn't be a big problem to fix them.

[dstogov]

Closed in favor to #2088