Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87718
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <04E6618E3189404FB15D042E588A90FC@pc1>
References: <B798F4D2069B4309AD72F91395561F38@pc1>
	<8BE12FDCDC5C457282790368866BD61E@pc1>
	<CA+9eiLuS3i8dMvzB-ZBW2Yd5DiacPtPc=xJz+4k+aqDqEGmJtw@mail.gmail.com>
	<04E6618E3189404FB15D042E588A90FC@pc1>
Date: Tue, 11 Aug 2015 22:15:01 +0200
Message-ID: <CAF+90c_gHt2A6gA6Kn6fq82BuhARJg6h3JuGUqXs1vXwiLtp4Q@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: PHP Internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=089e010d868cc6e17e051d0ec15b
Subject: Re: [PHP-DEV] Parameter parsing for zval type?
From: nikita.ppv@gmail.com (Nikita Popov)

--089e010d868cc6e17e051d0ec15b
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 11, 2015 at 10:10 PM, Matt Wilmas <php_lists@realplain.com>
wrote:

> Hi Dmitry,
>
>
> ----- Original Message -----
> From: "Dmitry Stogov"
> Sent: Tuesday, August 11, 2015
>
> Hi Matt,
>>
>>
>> On Tue, Aug 11, 2015 at 9:00 PM, Matt Wilmas <php_lists@realplain.com>
>> wrote:
>>
>> Hi again,
>>>
>>> ----- Original Message -----
>>> From: "Matt Wilmas"
>>> Sent: Tuesday, August 11, 2015
>>>
>>> Hi Dmitry, all,
>>>
>>>>
>>>> Help me understand this. :-)  It's been more puzzling to me recently
>>>> since just coming to the part of optimizing traditional ZPP (sharing
>>>> part
>>>> with FAST_ZPP...).
>>>>
>>>> With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and
>>>> Z_PARAM_ZVAL_DEREF?  It seems the zpp 'z' specifier is always like
>>>> ZVAL_DEREF, right?  So Z_PARAM_ZVAL has no equivalent in traditional
>>>> zpp.
>>>> At the very least, this would seem to suggest a difference in
>>>> behavior/functionality.  But I haven't found any (or bug reports, if
>>>> tests
>>>> didn't cover something).
>>>>
>>>>
>>> Oops!  No, plain zpp 'z' does not have ZVAL_DEREF() applied, of course.
>>> But it's also using zend_parse_arg_zval_DEREF(), which is wrong... (in
>>> the
>>> case of "z!" with reference to IS_NULL?).
>>>
>>
>>
>> Sorry. I don't understand you without context. If you think something is
>> wrong in current implementation - please, demonstrate it with test cases,
>> examples or code references. If you talk about your code, then show it.
>>
>
> Sorry, thought I gave enough context and code references!  I can't
> demonstrate with a test case, which is why I'm asking about it. :-)
>
> No, not my code changes (you'll have plenty of code to see soon).  I'm
> fine replicating the current logic exactly, as I have, but the logic of
> these couple parts doesn't make sense, to me.  Let me try to simplify with
> couple examples...
>
> Look at e.g. is_numeric() or strpos() (needle).  Plain zval param parsing,
> so NO ZVAL_DEREF() occurs (FAST_ZPP or traditional).  These 2 example
> functions don't handle IS_REFERENCE type, so they would break.
>
> Or is there no way for them (or any function?) to get a IS_REFERENCE?
> Then *why* is there ZVAL_DEREF() in param parsing functions?  We could
> remove it!
>
> Which is it...?
>

Functions accepting references are specially marked in arginfo. Normal
function argument can never be IS_REFERENCE. Reference arguments are always
IS_REFERENCE. There is also a rarely used mixed mode where both are
possible. For DEREF-or-not distinction is irrelevant for normal arguments,
it's only important if an argument is already marked to accept a ref.

Nikita

--089e010d868cc6e17e051d0ec15b--