Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89724
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <77.28.28320.361E5665@pb1.pair.com>
To: internals@lists.php.net
References: <5F562492D25B4650AD21E7B51AD3C6E5@pc1>
Date: Mon, 7 Dec 2015 19:43:24 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0)
 Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <5F562492D25B4650AD21E7B51AD3C6E5@pc1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Compilation fails without FAST_ZPP
From: ajf@ajf.me (Andrea Faulds)

Hi Matt,

Matt Wilmas wrote:
> Hi Bob, all,
>
> After this commit:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744
>
>
> In streamsfuncs.c, line 996 has an extra comma; and line 1511 has #ifdef
> instead of #ifndef ...
>
>
> BTW, maybe with the changes I'll propose, all this extra FAST_ZPP stuff
> can be cleaned up, for 7.1 at least.

Is it worth keeping these FAST_ZPP #ifdefs around, still? FAST_ZPP is 
probably here to stay, and what was the core (not the entirety) of 
FAST_ZPP is now always built regardless of whether the macro is defined, 
because it shares parameter-handling code with zend_parse_parameters and 
scalar type declarations.

One problem with keeping the #ifdefs is that the FAST_ZPP and 
zend_parse_parameters versions of argument handling can and do go out of 
sync. Also, I don't think it's even an actual compile-time option to 
disable FAST_ZPP anyway. You have to modify the source code and comment 
out the #define.

So, would there be any objection to getting rid of the #else branches in 
such #ifdefs?

Thanks!

-- 
Andrea Faulds
http://ajf.me/