Andrea Faulds wrote (on 24/09/2014):
Especially a BC break in a form of "it worked before but now it
>fails" - this can break code in so many hard to catch ways, where you
>didn't actually care at the least if the function truncates the arg
>(common situation in proxy/glue libraries, etc. - they'd be completely
>fine with garbage in - garbage out) but need special code to handle
>situations where the function fails to run altogether.
How do these libraries you speak of handle passing other types of arguments
that fail? Surely this isn’t a new phenomenon.
I think Stas's point was not that libraries don't need to think about
such things *in general*, but that the checking to handle *this
particular case* will not currently be in place, and might not be put in
place until someone is unfortunate enough to trigger the new behaviour.
That said, most cases of "garbage in, garbage out" would presumably
remain so, since most ZPP failures result in a return of NULL or FALSE,
which would probably end up cast back to the expected type (int(0),
string(''), etc) by the surrounding code.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
