In case this patch works, I think it's fine to include it.
Thanks. Dmitry.
On 02/12/2012 04:55 PM, yoram bar haim wrote:
I think the following patch is a better solution, currently trying it :
--- Zend/zend_execute.c.orig2012-02-12 14:32:07.0 +0200
+++ Zend/zend_execute.c 2012-02-12
The attatched patch solves the problem and I think it is more robust then
adding a new function.
calling a function like the proposed zend_restore_user_opcode_handler() might
be a problem in case someone else put handler before you.
instead of that it's easier to just tell zend_set_user_opcode_ha
I think the following patch is a better solution, currently trying it :
--- Zend/zend_execute.c.orig2012-02-12 14:32:07.0 +0200
+++ Zend/zend_execute.c 2012-02-12 14:31:33.0 +0200
@@ -1512,7 +1512,11 @@
ZEND_API int zend_set_user_opcode_handler(zend_uchar opcode,
user_opcode_h
Hi:
could you file a feature req on bugs.php.net?
I think it's okey to add a zend_restore_user_handler .
like:
ZEND_API int zend_restore_user_opcode_handler(zend_uchar opcode) {
zend_user_opcodes[opcode] = opcode;
zend_user_opcode_handlers[opcode] = NULL;
return SUCCESS;
}
I first saw this problem while addapting extension to PHP 5.4 but the code is
the same in 5.3 :
when you call zend_set_user_opcode_handler() it set's a pointer (handler) in
zend_user_opcode_handlers and a uint opcode value in zend_user_opcodes to
ZEND_USER_OPCODE .
you can call zend_set_user_op
