On Tue, Aug 11, 2015 at 10:10 PM, Matt Wilmas <php_li...@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_li...@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
