On 10/07/2011 10:04 AM, Pierre Joye wrote:
> especially when it is only about fixing a strict warning.
It's not _just_ about silencing a strict warning. It's about preventing
non-obvious fuck-ups in extensions as well, as I alluded to earlier in
the thread.
Consider an extension implementing a function like:
ZEND_BEGIN_ARG_INFO(arginfo_test, ZEND_SEND_PREFER_REF)
ZEND_END_ARG_INFO()
zend_function_entry test_functions[] = {
ZEND_FE(test, arginfo_test)
{NULL, NULL, NULL}
};
ZEND_FUNCTION(test)
{
zval ***argv;
int i, is_ref;
int argc = ZEND_NUM_ARGS();
argv = malloc(sizeof(zval **) * argc);
zend_get_parameters_array_ex(argc, argv);
for (i = 0; i < argc; i++) {
is_ref = PZVAL_IS_REF(*(argv[i]));
if (is_ref) {
/* Let's update it, and possibly
be in for a nice surprise */
if (Z_TYPE_PP(argv[i]) == IS_LONG)
Z_LVAL_PP(argv[i])++;
if (Z_TYPE_PP(argv[i]) == IS_STRING)
ZVAL_STRING(*argv[i], "surprise", 1);
}
zend_error(E_USER_NOTICE,
"Param %d was%s received by ref",
i, is_ref ? "" : " not");
}
free(argv);
RETURN_TRUE;
}
Then doing...
php -d extension=test.so -r '$a = 1; $b = 2; $str1 = "foo"; \
test($str1, $str2 = "bar", $a, $b = 3, NULL, "str"); \
echo "a: $a, b: $b, str1: $str1, str2: $str2\n";'
...would currently result in:
===
Notice: Param 0 was received by ref in Command line code on line 1
Notice: Param 1 was received by ref in Command line code on line 1
Notice: Param 2 was received by ref in Command line code on line 1
Notice: Param 3 was received by ref in Command line code on line 1
a: 2, b: 4, str1: surprise, str2: surprise
===
Which I think is a bit surprising in the case of 'b' and 'str2', whereas
after my patch it would be:
===
Notice: Param 0 was received by ref in Command line code on line 1
Notice: Param 1 was not received by ref in Command line code on line 1
Notice: Param 2 was received by ref in Command line code on line 1
Notice: Param 3 was not received by ref in Command line code on line 1
a: 2, b: 3, str1: surprise, str2: bar
===
Which I think is not as surprising.
> I would
> rather wait (maybe 5.4 last RC or final) before applying it to 5.3. We
> don't need a 5.3.7/8 again :)
Sure, it does not seem like people have been tripping over this left and
right, and given the change in behaviour, it may not be worth the risk.
That said, I'd be _very_ surprised, and a bit sad if anyone is relying
on the current buggy behaviour.
Daniel K.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
