Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87736
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: <7736C746A64A480AB3F285609E5DADB5@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><04E6618E3189404FB15D042E588A90FC@pc1> <CA+9eiLtK5DSCeVsMYqi-KbuaCwQk9p-Cpk4onP9Kgu1McOdvkg@mail.gmail.com>
Date: Wed, 12 Aug 2015 17:12:46 -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")

H Dmitry,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Tuesday, August 11, 2015

> On Tue, Aug 11, 2015 at 11:10 PM, Matt Wilmas <php_lists@realplain.com>
> wrote:
>
>> [...]
>>
>> 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.

Yes, speaking of scalars, I had already noticed that it doesn't make sense 
to have a "separate" argument for the FAST_ZPP scalar _EX macros, as there's 
nothing to separate (same with traditional '/') on simple values.  I was 
changing those macros, and don't think they're used anyway.

Also, I think those simple/scalar types wouldn't be used with by-reference 
arguments (?), as there would be nothing to update...

Like I said in reply to Nikita, it seems like separating is needed for 
by-reference args, so only need DEREF if *also* separating?  It looks like 
that was the idea with Z_PARAM_ZVAL_EX().  And for other types, separating 
only applies to arrays or strings, I believe.

As far as not 100% safe, you mean IS_REFERENCE type causing an error about 
wrong type?  Shouldn't that only happen if developer indicated by-ref arg, 
but then used wrong type in parsing?

On the other hand, it seems like always using ZVAL_DEREF() won't hurt 
anything? e.g. part of my confusion was that I thought IS_REFERENCE was 
wanting to be *kept* in some cases (after parsing), but it seems to not be 
the case. :-)

Speaking of confusion, it also seems the DEREF stuff is unnecessary in 
type.c:php_is_type(), for example.

> Thanks. Dmitry.

Thanks,
Matt