It's already done for strlen() - ZEND_STRLEN opcode (and few other
functions).
But it make no sense to convert all useful functions into opcodes.
We need an ability of fast parameter parsing anyway.
Thanks. Dmitry.
On Fri, Sep 5, 2014 at 5:55 AM, Stas Malyshev
wrote:
> Hi!
>
> > As I understa
--
Best Wishes,
Alexsunyx - PHP developer
Hi!
The first RC of the PHP 5.4.33 was just released and can be
downloaded from:
http://downloads.php.net/stas/
The Windows binaries are available at
http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, pleas
Hi!
> As I understand correctly the only reason we have this discussion is
> the performance impact of zpp with some functions, mainly
> ZEND_FUNCTIONs. What prevents us to make them operators? That may
> break things like call_user_func("strlen", $arg), array_map and the
There's also an issue t
On Thu, Sep 4, 2014 at 2:00 PM, Remi Collet wrote:
> For now:
>
> #define STR_REALLOC(ptr, size) \
> ptr = (char *) erealloc(ptr, size);
>
>
> Dealing with https://github.com/phalcon/cphalcon/pull/2772
>
> I switch from realloc to str_realloc.
> But this is not portable (s
On Thu, Sep 4, 2014 at 5:32 PM, Derick Rethans wrote:
> On Thu, 4 Sep 2014, Bob Weinand wrote:
>
> > After a long time… back to our fast_zpp RFC.
> >
> > Initially Dmitry proposed to have two different APIs, one for the fast
> version, one for current version:
> > #if FAST_ZPP
> > /* new API
On Thu, Sep 4, 2014 at 3:56 PM, Dmitry Stogov wrote:
> I like the idea of having a single syntax for all cases, but I don't like
> the syntax you propose.
> In my opinion, it's syntactically inconsistent, less readable and more
> error prone, than the old one (sscanf based) and the FAST_ZPP one th
I like the idea of having a single syntax for all cases, but I don't like
the syntax you propose.
In my opinion, it's syntactically inconsistent, less readable and more
error prone, than the old one (sscanf based) and the FAST_ZPP one that is
already in php-master.
I would also prefer to have an a
On Thu, 4 Sep 2014, Bob Weinand wrote:
> After a long time… back to our fast_zpp RFC.
>
> Initially Dmitry proposed to have two different APIs, one for the fast
> version, one for current version:
> #if FAST_ZPP
> /* new API */
> #else
> /* old style zend_parse_parameters API */
> #endif
On 4 Sep 2014, at 13:23, Bob Weinand wrote:
> After a long time… back to our fast_zpp RFC.
>
> Initially Dmitry proposed to have two different APIs, one for the fast
> version, one for current version:
> #if FAST_ZPP
>/* new API */
> #else
>/* old style zend_parse_parameters API */
> #
After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast version,
one for current version:
#if FAST_ZPP
/* new API */
#else
/* old style zend_parse_parameters API */
#endif
I don't really like the idea of having two different API
For now:
#define STR_REALLOC(ptr, size) \
ptr = (char *) erealloc(ptr, size);
Dealing with https://github.com/phalcon/cphalcon/pull/2772
I switch from realloc to str_realloc.
But this is not portable (str_realloc is 5.6+ only)
STR_REALLOC should be better, as portable,
Hello
PHP 5.5.17 RC1 is available for testing.
You can download it from
http://downloads.php.net/jpauli/
The Windows binaries are available at http://windows.php.net/qa/
This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to th
13 matches
Mail list logo
