Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender)
Message-ID: <0f4b980302f2f88a44608f8fe76c3195.squirrel@webmail.klapt.com>
In-Reply-To: <54D3D577.2060607@gmail.com>
References: <54D3D577.2060607@gmail.com>
Date: Fri, 6 Feb 2015 09:38:15 +0100
To: "Stanislav Malyshev" <smalyshev@gmail.com>
Cc: "PHP Internals" <internals@lists.php.net>
Reply-To: "Anatol Belski" <ab@php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] BC break in headers_list
From: ab@php.net ("Anatol Belski")

Hi Stas,

On Thu, February 5, 2015 21:41, Stanislav Malyshev wrote:
> Hi Anatol!
>
>
> Your recent fixes to headers_list() -
> 55cefb2814bde5815a92e8820fff45e037fa8d4f and
> b5d3c5ca8dee6303498849448e3574cc3642eeea - broke head.phpt test and also
> are BC-breaking since previously headers_list() always returned an array
> (empty one if there are no headers), now it returns false when there's
> no headers. As the manual also says it returns array, I would rather delete
> the RETURN_FALSE altogether. But if there's a good reason to return false,
> the tests should be fixed and the notes in the UPGRADING and the manual
> should be added. I think just reverting to the previous behavior is
> better. --
Thanks for the headsup, I must have missed that test. But despite that,
the condition there how it was (and is still everywhere, even in 5.4) is
erroneous. I mean "if (!&SG(sapi_headers).headers)" is always false, as
the sapi_headers member is a non-pointer, so taking its address is always
true.

So the intention was to correct that part to do what it actually looks
like. But since it was unlikely working and headers_list() was never
returning false and is documented to return array -  it's probably better
to just remove those three lines in 5.5 onwards (might be cut out by
optimizer anyway). Anyway agreed, no good reasons to force it to do what
it never did. I haven't dig deeper, maybe it was worky back then in early
PHP5 if "headers" were a pointer, but it doesn't behave as expected at
least since PHP5.4. I'm to remove that check it 5.5+ then.

Regards

Anatol