Hi Bob, all,
After this commit: 
http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744
In streamsfuncs.c, line 996 has an extra comma; and line 1511 has #ifdef 
instead of #ifndef ...
BTW, maybe with the changes I'll propose, all this extra FAST_ZPP stuff can 
be cleaned up, for 7.1 at least.
Thanks, 
Matt
Hi Matt,
Matt Wilmas wrote:
Hi Bob, all,
After this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744In streamsfuncs.c, line 996 has an extra comma; and line 1511 has #ifdef
instead of #ifndef ...BTW, maybe with the changes I'll propose, all this extra FAST_ZPP stuff
can be cleaned up, for 7.1 at least.
Is it worth keeping these FAST_ZPP #ifdefs around, still? FAST_ZPP is 
probably here to stay, and what was the core (not the entirety) of 
FAST_ZPP is now always built regardless of whether the macro is defined, 
because it shares parameter-handling code with zend_parse_parameters and 
scalar type declarations.
One problem with keeping the #ifdefs is that the FAST_ZPP and 
zend_parse_parameters versions of argument handling can and do go out of 
sync. Also, I don't think it's even an actual compile-time option to 
disable FAST_ZPP anyway. You have to modify the source code and comment 
out the #define.
So, would there be any objection to getting rid of the #else branches in 
such #ifdefs?
Thanks!
-- 
Andrea Faulds 
http://ajf.me/
Hi,
----- Original Message ---- 
From: "Andrea Faulds" 
Sent: Monday, December 07, 2015
Hi Matt,
Matt Wilmas wrote:
Hi Bob, all,
After this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=509712c7d9056b4ceb50134bfeea1a1115720744In streamsfuncs.c, line 996 has an extra comma; and line 1511 has #ifdef
instead of #ifndef ...BTW, maybe with the changes I'll propose, all this extra FAST_ZPP stuff
can be cleaned up, for 7.1 at least.Is it worth keeping these FAST_ZPP #ifdefs around, still? FAST_ZPP is
probably here to stay, and what was the core (not the entirety) of
FAST_ZPP is now always built regardless of whether the macro is defined,
because it shares parameter-handling code with zend_parse_parameters and
scalar type declarations.
Hold up on changes to the FAST_ZPP parts at this point! :-)  Like I [have] 
said, my changes are related and address that.  Sadly, the patch was 
supposed to be ready 3 months ago.  It's in the middle of beneficial 
refinement for the umpteenth time (first since summer, really :-D), and 
maybe it'll show up in a week or so this time.
Anyway, I was under the impression that the 2 #ifdef'd versions were for 
comparing the 2 methods (which is what I was doing), or if, even now, the 
inline parameter parsing wanted to be disabled, for smaller code size...
Besides the call sites, there's still stuff in zend_API.[ch] that's 
conditionally compiled...
My inline (FAST_ZPP alternative) solution can have the inline parsing part 
(which I'm trying to make as small as possible) disabled, and use a new 
zend_fast_parse_parameters(), or whatever it's called (also used with 
inlining if param type is wrong).  So, inlining or smallest [generated] code 
can be chosen with the same source.
A set of always_inline helper functions will also convert the old 
zend_parse_parameters functions to use the new FAST method (with all common 
compilers), without runtime string specifier parsing...  Generate code size 
<= current calls.
Since at least one new function is needed, not sure what could be changed in 
7.0 (I have some ideas), although there's also a faster function with 
runtime string parsing that IS fully compatible with 7.0.
One problem with keeping the #ifdefs is that the FAST_ZPP and
zend_parse_parameters versions of argument handling can and do go out of
sync. Also, I don't think it's even an actual compile-time option to
disable FAST_ZPP anyway. You have to modify the source code and comment
out the #define.
Yep and yep and yep.
So, would there be any objection to getting rid of the #else branches in
such #ifdefs?Thanks!
- Matt