FAQ
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.

So, questions:

1) Is the accepted practice that functions will return NULL when
zend_parse_parameters() fails in PHP5.3?

2) Is it acceptable to change the behaviour of functions between 5.2 and
5.3?

3) Does this apply to *all* PHP functions?

4) Assuming that the answer (3) is no, is there any documentation about
which functions have changed? (If not would you like some?)


Zoë

Search Discussions

  • Johannes Schlüter at Dec 19, 2008 at 11:56 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedDec 19, '08 at 9:19a
activeDec 19, '08 at 11:56a
posts2
users2
websitephp.net

2 users in discussion

Zoe: 1 post Johannes Schlüter: 1 post

People

Translate

site design / logo © 2022 Grokbase