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 Johannes, Johannes Schlüter wrote:

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.

I don't think changing of documented behaviour in minor version makes sense. And I don't see a lot of consistency in returning NULL in case each function documentation doesn't say it. Really, I would prefer special kind of exception. Thanks. Dmitry.

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