Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variation_001.phpt

Hi,

On Mon, 2009-03-16 at 09:52 +0000, "Dmitry Stogov" wrote:
> Log:
>   Fixed bug #47664 (get_class returns NULL instead of FALSE)
[...]
> @@ -716,7 +716,7 @@
>         int dup;
>  
>         if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o",
> &obj) == FAILURE) {
> -               return;
> +               RETURN_FALSE;
>         }

Usually we return NULL in case parameter parsing fails, this is
documented like this:

   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

This also applies to many other functions which usually return "false"
on error and are documented like that. Therefore I think returning NULL
in this case is a good thing in order to bring more consistency to the
language and I think this BC break is quite minor.

On a sidenote: There are cases where such a change has bigger effect: In
all cases where int(0)/string("") are "successful" return values and one
has to use type-safe comparison (think about strpos for instance) but in
this case I see more of a cleanup. Oh and the user should, usually,
check the types before passing the variable to the function ...

johannes