sorry, forgot to "reply to all"
http://bugs.php.net/bug.php?id=46850
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
this is a discussion about "Default value for parameters with a class
type hint can only be NULL" error
let's focus our eyes on
zend_compile.c function zend_do_receive_arg
void zend_do_receive_arg(zend_uchar op, const znode *var, const znode
*offset, const znode *initialization, znode *class
you're right, but too bad there's no PHP_FCGI_CHILDREN (pre-fork) for
windows, not even any alternatives
{{{
#ifndef PHP_WIN32
/* Pre-fork, if required */
if (getenv("PHP_FCGI_CHILDREN")) {
children = atoi(getenv("PHP_FCGI_CHILDREN"));
}}}
> No, why should it? The cache is shared p
XCache PHP_5_3 compatibility changeset is commited
http://xcache.lighttpd.net/changeset/548
{{{
$ svn co svn://svn.lighttpd.net/xcache/trunk
}}}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
session (or caused by TSRM/ZendEngine) seems broken in my local cvs
checkout i'm not sure if it's relatived to this patch but i did 'cvs
up' and some commit broke the patch (with conflicts)
please commit, or roll out another diff against the PHP_5_3 cvs so i
can test it again
thanks
--
PHP Inter
On Mon, Mar 10, 2008 at 5:59 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Dmitry,
>
> please don't apply. The patch looks rather rough and untested (see below).
> Also I really disagree to making the engine even more complex and adding
> even more different behavior ways. That way we ju
checked and it works, all test cases that pass without XCache now pass
with XCache too. i'll commit after your commit in ZendEngine
thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
gotcha, i'll check it within 24hours
thanks for your great work
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
i just hope the issue described in
http://www.mail-archive.com/internals@lists.php.net/msg32601.html will
be resolved before 5.3 is out. it is the only problem that breaks
opcode cacher support as far as i can see by now. e.g.: with this
problem fixed, all test cases will pass when XCache is enable
any news on this topic?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
> 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
=
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
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.
Bug #43128 Very long class name causes segfault [Zend
http://bugs.php.net/bug.php?id=43696
Description:
as you can see in zend_compile.c
opline->opcode = ZEND_INIT_NS_FCALL_BY_NAME;
ZEND_INIT_NS_FCALL_BY_NAME's op1 is initialized, so is op2
.
opline->opcode = ZEND_OP_DATA;
ZEND_OP_DATA's op1 is initialized here but
I think it's not worth doing unless there's overwhelming support as it's not
desperately needed. But I'd be interested to hear
people's thoughts. It seems implementation shouldn't be an issue but I'd have
to dive a bit deeper.
it sure acceptable for php users and will never be a conflict to "ph
the E_STRICT is an error type that issued at compile-time. and user
error handler is called, switching to runtime. mixing
runtime/compile-time is imho, not good, and cause problem in the real
world.
the flow:
script, include -> compiling, issue E_STRICT -> user error handler.
official bug:
1. se
geat job. it's much faster than valgrind. and can find 64bit/be etc problems.
it's something a must have like gcc printf format attribute.
u may have already notice: the line number is wrong sometimes.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
I think making it INI_PERDIR would mean a lot of headache and overcomplicated
code in the engine and the extensions that modify its behaviour (like APC).
i don't guess so. it's sure need upgrade but easy to implement, simply
put unicode.semantics into entry key, and hash/search by the key.
--
P
19 matches
Mail list logo
