Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94984
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.52 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <D2.BA.03404.E109AA75@pb1.pair.com>
References: <F4.52.16256.34F1A275@pb1.pair.com> <D2.BA.03404.E109AA75@pb1.pair.com>
Date: Tue, 9 Aug 2016 20:35:31 -0600
Message-ID: <CAFMT4Npgv+n9q16tU9RH8RGbwe3PN13GSi9CQGMLWtCtHZgzfw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec51f9709cf31120539ae80d7
Subject: Re: [PHP-DEV] Re: The death of `#ifndef FAST_ZPP`?
From: levim@php.net (Levi Morrison)

--bcaec51f9709cf31120539ae80d7
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 9, 2016 at 8:23 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi everyone,
>
> 3 months and 6 days on, nobody has responded to this.
>
> Will these chunks of dead code ever be removed?
>
> Thanks!
>
>
> Andrea Faulds wrote:
>
>> Hi everyone,
>>
>> You may recall that PHP 7.0 introduced a new API for processing
>> arguments to internal functions, the "Fast Parameter Parsing API" or
>> FAST_ZPP (https://wiki.php.net/rfc/fast_zpp), which is an alternative to
>> the existing zend_parse_parameters function family.
>>
>> Since FAST_ZPP was implemented, many functions in built-in PHP
>> extensions look like this:
>>
>> #ifndef FAST_ZPP
>>      if (zend_parse_parameters(ZEND_NUM_ARGS(), "S|S", &str, &what) ==
>> FAILURE) {
>>          return;
>>      }
>> #else
>>      ZEND_PARSE_PARAMETERS_START(1, 2)
>>          Z_PARAM_STR(str)
>>          Z_PARAM_OPTIONAL
>>          Z_PARAM_STR(what)
>>      ZEND_PARSE_PARAMETERS_END();
>> #endif
>>
>> That is, they have /two/ sets of parameter processing code: one using
>> the old API, and one using the new API, with conditional compilation.
>> This is necessary because it is still possible to turn off FAST_ZPP by
>> changing the value of the macro.
>>
>> However, should that be the case? The FAST_ZPP RFC was approved and PHP
>> 7.0 was released containing it enabled by default, so it's no longer
>> just an experimental performance enhancement. Furthermore, I have no
>> reason to believe that the option to turn off FAST_ZPP is actually used
>> in practice, though feel free to prove me wrong!
>>
>> Requiring all usages of FAST_ZPP to be accompanied by a
>> zend_parse_parameters() fallback creates code bloat. It also creates
>> hidden, potentially build-breaking bugs, because the code is rarely
>> built with FAST_ZPP disabled. It's like the old TSRMLS_CC situation.
>>
>> Furthermore, for those who would prefer the FAST_ZPP API, it is
>> inconvenient that they cannot use it exclusively and must also use
>> zend_parse_parameters(), doubling the effort.
>>
>> So, I would like to ask: would there be any objections to going through
>> and removing all unnecessary zend_parse_parameters fallbacks, and making
>> it impossible to disable FAST_ZPP? This would make the two APIs equally
>> valid.
>>
>> Thanks!
>>
>>
>
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

No objection from me.

--bcaec51f9709cf31120539ae80d7--