Le 15/02/2016 04:49, Stanislav Malyshev a écrit :
Hi!
This fix has been merged into master (targeting 7.1), thanks!
I'm not sure that was such a good idea (sorry, didn't have time to write
about it before the weekend). Introducing a new warning into previously
working code is a BC break, and one that wasn't even discussed in its
own thread. Moreover, there's one more BC break in this patch - before
it, for this code:
$str = "abc";
$str{4} = '';
var_dump($str);
the $str was string of length 5, with this fix it would be string of
length 3, unchanged. Which may break other code (e.g. one composing
complex formats) in very subtle ways. And I'm not sure that current
behavior is an improvement.
Right. Introducing a BC break in a minor version requires a consensus,
and we should probably have discussed about it on the list, instead of
github. So, let's discuss it further.
As we probably agree that introducing a null byte in the string is a
bug, what fix would you suggest ?
If we consider the BC break too important for a minor version, another
solution could be to consider an empty RHS string as a space character,
because this is the padding char used when extending the string. There,
we can keep almost the same behavior as the current one, except we put a
space instead of a null byte and, maybe, raise an E_NOTICE. So, your
example would cause $str to become "abc " instead of "abc \0" and the
assignement would return " " instead of "\0".
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
