Re: date() behaviour changed in 5.1?

Jani Taskinen wrote:

    If you pass bad data to a function, it should not warn you?
    I'd rather have it as a FATAL error. :)

    Nothing to fix here, move along. (and fix your code..)

The issue here is we effectively have two different casting mechanisms. One of the things we need to do when moving to PHP 6 is to make sure everything is using zend_parse_parameters() to handle function parameters. Most people would assume that a function that wasn't using zend_parse_parameters() before and was defined to take a long and thus passed the parameter through convert_to_long() wouldn't change its behaviour when moved to zend_parse_parameters() with an "l". That is: zval **foo; long lfoo; zend_get_parameters_ex(1, &foo) convert_to_long_ex(foo); lfoo = Z_LVAL_PP(foo); is not equivalent to: long foo; zend_parse_parameters(1, "l", &foo); In order to not change the behaviour of the function moving to zend_parse_parameters() from zend_get_parameters() you have to use a "z" and do the convert_to_long yourself. The reason for this is that is_numeric_string() has a flag called allow_errors which specifies whether or not it should be strict. When you cast from PHP or use one of the conversion functions internally this flag is off. When calling zend_parse_parameters it is on. I am not sure what the right answer here is. I can see the argument for being strict on parameter types, but at the same time, we will potentially be breaking a lot of existing code. And at a higher level I don't like the concept of having two different casting modes. -Rasmus