Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68715
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.180 as permitted sender)
Message-ID: <52207782.5050204@gmail.com>
Date: Fri, 30 Aug 2013 11:44:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Julien Pauli <jpauli@php.net>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c_i7bU0CGPiA4pgL+d+C+Py1279DTYRivQnSorhc9oq7Q@mail.gmail.com> <CAF+90c8pnaj1s_tsYDZz5G3G6uD2J0CNdRh1yhB_TWSNhZgxdw@mail.gmail.com> <521FE78E.3060900@gmail.com> <CAMUwpuQ2s8jM7S4ZXBegq=ec_pjhWvZ90NDXS2c1jMJChuJCCg@mail.gmail.com>
In-Reply-To: <CAMUwpuQ2s8jM7S4ZXBegq=ec_pjhWvZ90NDXS2c1jMJChuJCCg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------010504010107000703040202"
Subject: Re: [PHP-DEV] Re: Always set return_value_ptr?
From: ellison.terry@gmail.com (Terry Ellison)

--------------010504010107000703040202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------010504010107000703040202--