Re: Re: Always set return_value_ptr?

On 30/08/13 10:43, Julien Pauli wrote:

On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison <ellison.terry@gmail.com <mailto:ellison.terry@gmail.com>> wrote:

    There's another one in string.c, in PHP_FUNCTION(pathinfo), that
    could be applied as well, though there's little performance gain
    in avoiding the copy of a 4 element string array.

    BTW, looking at this pathinfo code, it doesn't do what the
    documentation says it does -- or at least this states that the
    optional argument if present should be _one_ of PATHINFO_DIRNAME,
    PATHINFO_BASENAME, PATHINFO_EXTENSION or PATHINFO_FILENAME.
    However, if a bitmask is supplied then this function returns the
    element corresponding to the lowest bit value rather than an error
    return, for example:

    $ php -r 'echo pathinfo("/tmp/x.fred",
    PATHINFO_FILENAME|PATHINFO_EXTENSION),"\n";'
    fred

    This is a bizarre behaviour.   At a minimum the documentation
    should actually state what the function does. Or do we bother to
    raise a patch to fix this sort of thing, given that returning an
    empty string (or more consistently with other functions, NULL) in
    this case could create a BC break with existing buggy code?

This is weird, yes. It's not the lowest bit value that is returned, but the first element put in the array (as zend_hash_get_current_data() is used with no HashPosition) , which is even more confusing. How to explain that in the documentation ? :|

Yes I understand that, but the code processes the elements in this dirname, basename, filename, extension order so the two statements are equivalent in implementation. I am an experienced developer but a newbie-ish to the PHP developer community, and I come back to my Q. What do we typically do if we come across such weird functional behaviour outside the documented use of a standard function? * Shrug our shoulders and say "That's PHP for you. BC rules" * Fix the documentation to say what the code actually does * Fix the code at the next major release, say 5.6 to have sensible error behaviour. Just interested in understanding the consensus policy here. Do I post a fix to the doc; post a fix to the code; or move on to other issues? Regards Terry