more pitfall: apc and XCache uses fast copy of opcodes for restoring
opcode, but this will never work if early binding which have to modify
opcodes is done after restore
see apc_copy_op_array_for_execution() in apc_compile.c
there is my_copy_data_exceptions(dst, src); which do a check if to deep co
On 2007-12-30 04:16, phpxcache wrote:
> i have the following settings in my /etc/php.ini
> pcre.backtrack_limit=1
> pcre.recursion_limit=1000
> test case
> ini_get_all() tests [ext/standard/tests/general_functions/ini_get_all.phpt]
> FAIL. but after i remove the settings, it will PASS.
>
>
> Compiler shouldn't generate different code. Unqualified name is resolved
> at runtime, but code should be the same whatever resolution was made.
> Did you check that different code is indeed generated?
zend_compile.c
===
if (zend_hash_find(CG(class_table), lc
These both tests should just have the INI section with proper settings.
--Jani
On Sun, 2007-12-30 at 11:16 +0800, phpxcache wrote:
> i have the following settings in my /etc/php.ini
> pcre.backtrack_limit=1
> pcre.recursion_limit=1000
> test case
> ini_get_all() tests [ext/standard/tests
5.3 namespace code will check for CG(class_table) and see if a class
is internal class to generate different code.
Compiler shouldn't generate different code. Unqualified name is resolved
at runtime, but code should be the same whatever resolution was made.
Did you check that different code i
On Dec 29, 2007 12:45 AM, Ryusuke SEKIYAMA <[EMAIL PROTECTED]> wrote:
> >any idea about the possibility of hash conflict?
>
> How about this patch?
> http://www.opendogs.org/pub/php-5.3dev-071228a.patch
yeah build_runtime_defined_function_key! that's what i thought of :)
and i hope the function nam
=
original problem
=
the biggest problem caused by early class binding is that it's
unfriendly to opcode cachers.
parent1.php
class P
{
function __construct()
{
echo "parent2";
}
}
include "child.php"
==
parent2.php
class P
{
function __constr
