As for handling invalid input, I think you should actually check what some of the functions output some day.
For example, decbin clearly states that the input should be an integer but if I pass it a string.....
Code/ctsr ยป php -r 'echo decbin("invalid input");' 0%
Zero is clearly not a NULL value. This is one I ran into this morning with php 5.3.8, I've seen this issue crop up in many other functions, they don't return NULL. Some return NULL, some return 0, some return '', some return '0', some return FALSE.
I think a simple "use strict"-type declaration would go a long way for making software that's actually reliable rather than the barrage of set_error_handler, ini_set and related calls, but oh well, I'll file a feature request. It gets more complicated when security enters the mix (remember magic quotes?), but there are about nine thousand different frameworks which deal with that better since they're actually designed for a specific purpose.
It's trivial to turn all notices/warnings/errors into exceptions in PHP (it even provides an exception class for it, ErrorException). PHP is multi-paradigm and supports many different ways of handling errors and warnings.
> This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily.
This change was to make the output of functions consistent based on invalid input. It's specifically addressing this point. It's also the very first point listed in the migration documentation
http://au2.php.net/manual/en/migration53.incompatible.php