Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 216.33.127.80 cause and error)
Message-ID: <04E6618E3189404FB15D042E588A90FC@pc1>
To: "PHP Internals" <internals@lists.php.net>,
	"Dmitry Stogov" <dmitry@zend.com>
References: <B798F4D2069B4309AD72F91395561F38@pc1><8BE12FDCDC5C457282790368866BD61E@pc1> <CA+9eiLuS3i8dMvzB-ZBW2Yd5DiacPtPc=xJz+4k+aqDqEGmJtw@mail.gmail.com>
Date: Tue, 11 Aug 2015 15:10:50 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Parameter parsing for zval type?
From: php_lists@realplain.com ("Matt Wilmas")

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...?

> Thanks. Dmitry.

Thanks,
Matt