Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.182 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 23:27:48 +0300
Message-ID: <CA+9eiLtK5DSCeVsMYqi-KbuaCwQk9p-Cpk4onP9Kgu1McOdvkg@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc05f283abf9051d0eef1a
Subject: Re: [PHP-DEV] Parameter parsing for zval type?
From: dmitry@zend.com (Dmitry Stogov)

--047d7bdc05f283abf9051d0eef1a
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 11, 2015 at 11: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!
>

We probably may remove ZVAL_DEREF() for functions arguments passed by
value, but we don't know if argument was passed by value or by reference in
ZPP functions. Actually, in FAST_ZPP for scalars we may probably assume
passing by value and remove ZVAL_DEREF(), but I'm not sure if this is 100%
safe.

Thanks. Dmitry.


>
> Which is it...?
>
> Thanks. Dmitry.
>>
>
> Thanks,
> Matt
>

--047d7bdc05f283abf9051d0eef1a--