Hi,
On Fri, 2008-12-19 at 09:18 +0000, zoe wrote:
> Hi Lukas, Johannes
>
> Please could I ask for a PHP5.3 release manager's point of view on this?
> I raised this ext/imap bug yesterday
> http://bugs.php.net/bug.php?id=46902 after a discussion with Ilia
> because I noticed that all of the function return values which result
> from a failure of parameter parsing had changed from 'false' in PHP5.2
> to NULL in PHP5.3.
> 1) Is the accepted practice that functions will return NULL when
> zend_parse_parameters() fails in PHP5.3?
"If the parameters given to a function are not what it expects, such
as passing an array where a string is expected, the return value of
the function is undefined. In this case it will likely return NULL
but this is just a convention, and cannot be relied upon."
http://www.php.net/manual/en/functions.internal.php
> 2) Is it acceptable to change the behaviour of functions between 5.2 and
> 5.3?
In most cases a wrong parameter parsing should happen during development
not in production so there shouldn't be a too big impact for productive
systems. But I know people doing strange things. Since null == false in
most situations the change from false to NULL shouldn't be noticed.
Changing the return value might even help to make PHP more consistent
and follow the docs (as above). But ...
> 3) Does this apply to *all* PHP functions?
... there might be exceptions. Some functions, like strpos(), might
return 0 as a successful value and false for errors. So people check
using strpos !== false which won't catch all errors when returning NULL.
The interesting part there is that strpos() follows the "return NULL on
param parsing error"-rule in 5.2 already. So in that case changing the
return value the other way round might make the code more robust ;-)
The same goes, btw. for fgets - string(1) "0" might be a valid return
value, so people might check using === false for a general error, but
5.2 returns NULL for wrong parameter parsing.
> 4) Assuming that the answer (3) is no, is there any documentation about
> which functions have changed? (If not would you like some?)
>From top of my head I don't see another function where this is relevant.
And in my opinion somebody who depends on wrong parameter parsing does
things wrong. If then checking for false using === the user also depends
on not strictly defined behavior (see quote from above again)
But I'd like others to think about edge cases like strpos(),
fgets(), ... where a value evaluating to false is a successful return
value or other related edge cases .. (is there any place where one uses
wrong parameters on purpose?)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
