Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
Seems to be a windows only problem for me. Works fine under linux, but
I've tried 3 different builds of the ICU library - even built one from
source - and it always crashes at the same point within the ucol_close call.
Rob
Andrei Zmievski wrote:
Strange. I don't see it here on FreeBSD. Does anyone else have this
problem?
-A
On Oct 3, 2006, at 4:56 AM, Rob Richards wrote:
I get consistent crashes on windows during shutdown with this change.
Access violation in the dtor at:
ucol_close(unicode_globals-root_collator);
It did open correctly as:
unicode_globals-root_collator = ucol_open(en_US, status);
returned -128, which is supposedly successful.
I already tried upgrading ICU to 3.4.1 but still same problem.
Rob
Andrei Zmievski wrote:
andreiFri Sep 29 20:59:26 2006 UTC
Modified files: /ZendEngine2zend.c
zend_globals.h zend_unicode.c Log:
Fix off-by-one error.
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c?r1=1.372r2=1.373diff_format=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.372 ZendEngine2/zend.c:1.373
--- ZendEngine2/zend.c:1.372Tue Sep 19 20:44:37 2006
+++ ZendEngine2/zend.cFri Sep 29 20:59:26 2006
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: zend.c,v 1.372 2006/09/19 20:44:37 andrei Exp $ */
+/* $Id: zend.c,v 1.373 2006/09/29 20:59:26 andrei Exp $ */
#include zend.h
#include zend_extensions.h
@@ -929,11 +929,26 @@
unicode_globals-to_error_mode = ZEND_CONV_ERROR_STOP;
unicode_globals-conv_error_handler = NULL;
+{
+UErrorCode status = U_ZERO_ERROR;
+
+unicode_globals-root_collator = ucol_open(en_US, status);
+ucol_setStrength(unicode_globals-root_collator,
UCOL_PRIMARY);
+unicode_globals-root_search =
usearch_openFromCollator(EMPTY_STR, 1, EMPTY_STR, 1,
+
unicode_globals-root_collator, NULL, status);
+}
+
zend_hash_init_ex(unicode_globals-flex_compatible, 0, NULL,
NULL, 1, 0);
}
static void unicode_globals_dtor(zend_unicode_globals
*unicode_globals TSRMLS_DC)
{
+if (unicode_globals-root_collator) {
+ucol_close(unicode_globals-root_collator);
+}
+if (unicode_globals-root_search) {
+usearch_close(unicode_globals-root_search);
+}
if (unicode_globals-fallback_encoding_conv) {
ucnv_close(unicode_globals-fallback_encoding_conv);
--PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
I suppose we can omit the ucol_close() call since we're shutting down
completely and ICU will close all resources anyway on exit, I believe.
-Andrei
On Oct 4, 2006, at 6:28 AM, Rob Richards wrote:
Seems to be a windows only problem for me. Works fine under linux, but
I've tried 3 different builds of the ICU library - even built one from
source - and it always crashes at the same point within the ucol_close
call.
Rob
Andrei Zmievski wrote:
Strange. I don't see it here on FreeBSD. Does anyone else have this
problem?
-A
On Oct 3, 2006, at 4:56 AM, Rob Richards wrote:
I get consistent crashes on windows during shutdown with this change.
Access violation in the dtor at:
ucol_close(unicode_globals-root_collator);
It did open correctly as:
unicode_globals-root_collator = ucol_open(en_US, status);
returned -128, which is supposedly successful.
I already tried upgrading ICU to 3.4.1 but still same problem.
Rob
Andrei Zmievski wrote:
andreiFri Sep 29 20:59:26 2006 UTC
Modified files: /ZendEngine2zend.c
zend_globals.h zend_unicode.c Log:
Fix off-by-one error.
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c?
r1=1.372r2=1.373diff_format=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.372 ZendEngine2/zend.c:1.373
--- ZendEngine2/zend.c:1.372Tue Sep 19 20:44:37 2006
+++ ZendEngine2/zend.cFri Sep 29 20:59:26 2006
@@ -17,7 +17,7 @@
+---
---+
*/
-/* $Id: zend.c,v 1.372 2006/09/19 20:44:37 andrei Exp $ */
+/* $Id: zend.c,v 1.373 2006/09/29 20:59:26 andrei Exp $ */
#include zend.h
#include zend_extensions.h
@@ -929,11 +929,26 @@
unicode_globals-to_error_mode = ZEND_CONV_ERROR_STOP;
unicode_globals-conv_error_handler = NULL;
+{
+UErrorCode status = U_ZERO_ERROR;
+
+unicode_globals-root_collator = ucol_open(en_US,
status);
+ucol_setStrength(unicode_globals-root_collator,
UCOL_PRIMARY);
+unicode_globals-root_search =
usearch_openFromCollator(EMPTY_STR, 1, EMPTY_STR, 1,
+
unicode_globals-root_collator, NULL, status);
+}
+
zend_hash_init_ex(unicode_globals-flex_compatible, 0, NULL,
NULL, 1, 0);
}
static void unicode_globals_dtor(zend_unicode_globals
*unicode_globals TSRMLS_DC)
{
+if (unicode_globals-root_collator) {
+ucol_close(unicode_globals-root_collator);
+}
+if (unicode_globals-root_search) {
+usearch_close(unicode_globals-root_search);
+}
if (unicode_globals-fallback_encoding_conv) {
ucnv_close(unicode_globals-fallback_encoding_conv);
--PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
That does prevent the crash. I did find that within zend_shutdown, if I comment out the call to u_cleanup(), then ucol_close doesn't crash within unicode_globals_dtor during tsrm_shutdown. If that helps any. Rob Andrei Zmievski wrote: I suppose we can omit the ucol_close() call since we're shutting down completely and ICU will close all resources anyway on exit, I believe. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
Strange. I don't see it here on FreeBSD. Does anyone else have this
problem?
-A
On Oct 3, 2006, at 4:56 AM, Rob Richards wrote:
I get consistent crashes on windows during shutdown with this change.
Access violation in the dtor at:
ucol_close(unicode_globals-root_collator);
It did open correctly as:
unicode_globals-root_collator = ucol_open(en_US, status);
returned -128, which is supposedly successful.
I already tried upgrading ICU to 3.4.1 but still same problem.
Rob
Andrei Zmievski wrote:
andrei Fri Sep 29 20:59:26 2006 UTC
Modified files: /ZendEngine2 zend.c zend_globals.h
zend_unicode.c Log:
Fix off-by-one error.
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c?
r1=1.372r2=1.373diff_format=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.372 ZendEngine2/zend.c:1.373
--- ZendEngine2/zend.c:1.372Tue Sep 19 20:44:37 2006
+++ ZendEngine2/zend.c Fri Sep 29 20:59:26 2006
@@ -17,7 +17,7 @@
+-
-+
*/
-/* $Id: zend.c,v 1.372 2006/09/19 20:44:37 andrei Exp $ */
+/* $Id: zend.c,v 1.373 2006/09/29 20:59:26 andrei Exp $ */
#include zend.h
#include zend_extensions.h
@@ -929,11 +929,26 @@
unicode_globals-to_error_mode = ZEND_CONV_ERROR_STOP;
unicode_globals-conv_error_handler = NULL;
+ {
+ UErrorCode status = U_ZERO_ERROR;
+
+ unicode_globals-root_collator = ucol_open(en_US, status);
+ ucol_setStrength(unicode_globals-root_collator, UCOL_PRIMARY);
+ unicode_globals-root_search = usearch_openFromCollator(EMPTY_STR,
1, EMPTY_STR, 1,
+
unicode_globals-root_collator, NULL,
status);
+ }
+
zend_hash_init_ex(unicode_globals-flex_compatible, 0, NULL, NULL,
1, 0);
}
static void unicode_globals_dtor(zend_unicode_globals
*unicode_globals TSRMLS_DC)
{
+ if (unicode_globals-root_collator) {
+ ucol_close(unicode_globals-root_collator);
+ }
+ if (unicode_globals-root_search) {
+ usearch_close(unicode_globals-root_search);
+ }
if (unicode_globals-fallback_encoding_conv) {
ucnv_close(unicode_globals-fallback_encoding_conv);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I agree with all of this. Anyone want to update README.UNICODE to reflect this change? -Andrei On Aug 16, 2005, at 4:52 PM, Andi Gutmans wrote: I think we should make the following assumptions: a) Being able to create and manipulate IS_UNICODE zvals when unicode_semantics=off will be very useful to people including the exposing of the ICU extension. b) Defining Unicode identifiers like classes/properties/functions if unicode_semantics=off does not seem useful and should be prohibited. c) People can always find ways of misusing the language apis to reach a state which they shouldn't be reaching, For example, assuming (a) (b) using create_function to misuse the engine and create a Unicode function name when Unicode=off. I don't believe we can or should enforce every possibility of misuse or we'll bloat the code and will never reach perfection. That said, we probably can enforce the obvious places where people try to define unicode classes/functions/properties when unicode_semantics=off. btw, I'm only referring to identifiers. If unicode=off then i believe things like arrays should support IS_UNCODE keys/values in addition to IS_STRING for reasons as in (a). As per original design those two wouldn't match though as they would when we're in full blown unicode mode. Dmitry, do you thing that not allowing unicode identifiers when unicode=off would be hard to accomplish? it would make life easier when it comes to code that sparked this discussion (and maybe harder in other cases). Due to (c) I'm king of worried of trying to simplify the model and we might just need to provide eaier to use apis to extension writers which would save them effort in checking the different options. A ggood API is key in making sure that we get a consistent implementation and upgrade of php functions. Andi At 03:13 PM 8/16/2005 -0700, Andrei Zmievski wrote: It does make the engine more complicated though, because we can't just check for UG(unicode) and expect all identifiers to be of the same type. We would actually need to amend a lot of API functions to include passing the identifier type along, e.g. zend_get_active_function() would need to return the identifier type along with the identifier itself. -Andrei On Aug 16, 2005, at 1:36 PM, Andi Gutmans wrote: IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hmm, should we allow this? It is much easier to deal with having common
identifier type everywhere.
-Andrei
On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote:
You aren't right.
It is posiible to have unicode property in non-unicode mode (class
name is
string and property name is unicode).
?php
$obj = new stdClass();
$obj-{(unicode)asd} = 1;
var_dump($obj);
?
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 11:36 PM
To: Dmitry Stogov
Cc: [EMAIL PROTECTED]
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Dmitry,
ah that's the point i didn't get. Anyway still prop_name
and class_name are the same string type so still it should be
zend_printf(%R:%R:private, ztype, prop_name, ztype,
class_name); instead of zend_printf(%R:%v:private, ztype,
prop_name, class_name);
can you please check?
regards
marcus
Monday, August 15, 2005, 4:43:49 PM, you wrote:
In unicode mode class_names are always unicode.
The key_type is not IS_UNICODE but ZEND_HASH_KEY_UNICODE in
this code.
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 12:34 PM
To: Dmitry Stogov
Cc: [EMAIL PROTECTED]
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Dmitry,
what does this fix? The names are stored in the same value
and thus should either be both unicode or native strings. Did
you find something else?
marcus
Monday, August 15, 2005, 9:12:55 AM, you wrote:
dmitry Mon Aug 15 03:12:55 2005 EDT
Modified files:
/ZendEngine2zend.c
Log:
Fixed another print_r() bug
http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.314r2=1.315ty=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.314 ZendEngine2/zend.c:1.315
--- ZendEngine2/zend.c:1.314Mon Aug 15 02:34:20 2005
+++ ZendEngine2/zend.c Mon Aug 15 03:12:52 2005
@@ -17,7 +17,7 @@
+-
-+
*/
-/* $Id: zend.c,v 1.314 2005/08/15 06:34:20 dmitry Exp $ */
+/* $Id: zend.c,v 1.315 2005/08/15 07:12:52 dmitry Exp $ */
#include zend.h
#include zend_extensions.h
@@ -276,7 +276,7 @@
if
(class_name[0]=='*') {
zend_printf(%R:protected, ztype, prop_name);
} else {
-
zend_printf(%R:%R:private, ztype, prop_name, key_type,
class_name);
+
zend_printf(%R:%v:private, ztype, prop_name, class_name);
}
} else {
zend_printf(%R,
ztype, prop_name);
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Andrei,
i am actually convinced that property and class names should always be of
same string type at least for the property key. If not then how the heck can
we ensure that the code will work? That's why i was asking for %R being used
twice and referencing the same type, that of the hash.
Another thing is if we simply shouldn't treat all class/prop/fun names as
native strings if unicode is off and as unicode strings if it is on. Or do
you guys think that would be a too great slowdown?
regards
marcus
Tuesday, August 16, 2005, 7:30:37 PM, you wrote:
Hmm, should we allow this? It is much easier to deal with having common
identifier type everywhere.
-Andrei
On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote:
You aren't right.
It is posiible to have unicode property in non-unicode mode (class
name is
string and property name is unicode).
?php
$obj = new stdClass();
$obj-{(unicode)asd} = 1;
var_dump($obj);
?
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 11:36 PM
To: Dmitry Stogov
Cc: [EMAIL PROTECTED]
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Dmitry,
ah that's the point i didn't get. Anyway still prop_name
and class_name are the same string type so still it should be
zend_printf(%R:%R:private, ztype, prop_name, ztype,
class_name); instead of zend_printf(%R:%v:private, ztype,
prop_name, class_name);
can you please check?
regards
marcus
Monday, August 15, 2005, 4:43:49 PM, you wrote:
In unicode mode class_names are always unicode.
The key_type is not IS_UNICODE but ZEND_HASH_KEY_UNICODE in
this code.
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 12:34 PM
To: Dmitry Stogov
Cc: [EMAIL PROTECTED]
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Dmitry,
what does this fix? The names are stored in the same value
and thus should either be both unicode or native strings. Did
you find something else?
marcus
Monday, August 15, 2005, 9:12:55 AM, you wrote:
dmitry Mon Aug 15 03:12:55 2005 EDT
Modified files:
/ZendEngine2zend.c
Log:
Fixed another print_r() bug
http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.314r2=1.315ty=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.314 ZendEngine2/zend.c:1.315
--- ZendEngine2/zend.c:1.314Mon Aug 15 02:34:20 2005
+++ ZendEngine2/zend.c Mon Aug 15 03:12:52 2005
@@ -17,7 +17,7 @@
+-
-+
*/
-/* $Id: zend.c,v 1.314 2005/08/15 06:34:20 dmitry Exp $ */
+/* $Id: zend.c,v 1.315 2005/08/15 07:12:52 dmitry Exp $ */
#include zend.h
#include zend_extensions.h
@@ -276,7 +276,7 @@
if
(class_name[0]=='*') {
zend_printf(%R:protected, ztype, prop_name);
} else {
-
zend_printf(%R:%R:private, ztype, prop_name, key_type,
class_name);
+
zend_printf(%R:%v:private, ztype, prop_name, class_name);
}
} else {
zend_printf(%R,
ztype, prop_name);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I couldn't parse this. Could you restate your question? -Andrei On Aug 16, 2005, at 11:40 AM, Marcus Boerger wrote: Another thing is if we simply shouldn't treat all class/prop/fun names as native strings if unicode is off and as unicode strings if it is on. Or do you guys think that would be a too great slowdown? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets
and properties (and do auto-conversion). however, if unicode = off, we
should not do auto conversion but allow php users to manually create
unicode data. when it comes to arrays we agreed that in this case they can
use strings and unicode as they wish (makes sense for apps that can't make
the complete move but can unicode-enable some of the app, for example, a
web service).
so bottom line, i dont think we can expect class name and property to be in
the same encoding unless we hard code it, but i like the flexibility of
being able to use unicode strings when unicode_semantics is off
(this took me far too long to write :)
At 10:30 AM 8/16/2005 -0700, Andrei Zmievski wrote:
Hmm, should we allow this? It is much easier to deal with having common
identifier type everywhere.
-Andrei
On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote:
You aren't right.
It is posiible to have unicode property in non-unicode mode (class name is
string and property name is unicode).
?php
$obj = new stdClass();
$obj-{(unicode)asd} = 1;
var_dump($obj);
?
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 11:36 PM
To: Dmitry Stogov
Cc: [EMAIL PROTECTED]
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Dmitry,
ah that's the point i didn't get. Anyway still prop_name
and class_name are the same string type so still it should be
zend_printf(%R:%R:private, ztype, prop_name, ztype,
class_name); instead of zend_printf(%R:%v:private, ztype,
prop_name, class_name);
can you please check?
regards
marcus
Monday, August 15, 2005, 4:43:49 PM, you wrote:
In unicode mode class_names are always unicode.
The key_type is not IS_UNICODE but ZEND_HASH_KEY_UNICODE in
this code.
Dmitry.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 12:34 PM
To: Dmitry Stogov
Cc: [EMAIL PROTECTED]
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Dmitry,
what does this fix? The names are stored in the same value
and thus should either be both unicode or native strings. Did
you find something else?
marcus
Monday, August 15, 2005, 9:12:55 AM, you wrote:
dmitry Mon Aug 15 03:12:55 2005 EDT
Modified files:
/ZendEngine2zend.c
Log:
Fixed another print_r() bug
http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.314r2=1.315ty=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.314 ZendEngine2/zend.c:1.315
--- ZendEngine2/zend.c:1.314Mon Aug 15 02:34:20 2005
+++ ZendEngine2/zend.c Mon Aug 15 03:12:52 2005
@@ -17,7 +17,7 @@
+-
-+
*/
-/* $Id: zend.c,v 1.314 2005/08/15 06:34:20 dmitry Exp $ */
+/* $Id: zend.c,v 1.315 2005/08/15 07:12:52 dmitry Exp $ */
#include zend.h
#include zend_extensions.h
@@ -276,7 +276,7 @@
if
(class_name[0]=='*') {
zend_printf(%R:protected, ztype, prop_name);
} else {
-
zend_printf(%R:%R:private, ztype, prop_name, key_type,
class_name);
+
zend_printf(%R:%v:private, ztype, prop_name, class_name);
}
} else {
zend_printf(%R,
ztype, prop_name);
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
It does make the engine more complicated though, because we can't just check for UG(unicode) and expect all identifiers to be of the same type. We would actually need to amend a lot of API functions to include passing the identifier type along, e.g. zend_get_active_function() would need to return the identifier type along with the identifier itself. -Andrei On Aug 16, 2005, at 1:36 PM, Andi Gutmans wrote: IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I think we should make the following assumptions: a) Being able to create and manipulate IS_UNICODE zvals when unicode_semantics=off will be very useful to people including the exposing of the ICU extension. b) Defining Unicode identifiers like classes/properties/functions if unicode_semantics=off does not seem useful and should be prohibited. c) People can always find ways of misusing the language apis to reach a state which they shouldn't be reaching, For example, assuming (a) (b) using create_function to misuse the engine and create a Unicode function name when Unicode=off. I don't believe we can or should enforce every possibility of misuse or we'll bloat the code and will never reach perfection. That said, we probably can enforce the obvious places where people try to define unicode classes/functions/properties when unicode_semantics=off. btw, I'm only referring to identifiers. If unicode=off then i believe things like arrays should support IS_UNCODE keys/values in addition to IS_STRING for reasons as in (a). As per original design those two wouldn't match though as they would when we're in full blown unicode mode. Dmitry, do you thing that not allowing unicode identifiers when unicode=off would be hard to accomplish? it would make life easier when it comes to code that sparked this discussion (and maybe harder in other cases). Due to (c) I'm king of worried of trying to simplify the model and we might just need to provide eaier to use apis to extension writers which would save them effort in checking the different options. A ggood API is key in making sure that we get a consistent implementation and upgrade of php functions. Andi At 03:13 PM 8/16/2005 -0700, Andrei Zmievski wrote: It does make the engine more complicated though, because we can't just check for UG(unicode) and expect all identifiers to be of the same type. We would actually need to amend a lot of API functions to include passing the identifier type along, e.g. zend_get_active_function() would need to return the identifier type along with the identifier itself. -Andrei On Aug 16, 2005, at 1:36 PM, Andi Gutmans wrote: IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
andi Tue Jun 1 07:45:46 2004 EDT
Modified files:
/ZendEngine2 zend.c
Log:
- If user error handler returns false then we relay to the built in error
handler
http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284r2=1.285ty=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285
--- ZendEngine2/zend.c:1.284 Fri May 28 13:28:33 2004
+++ ZendEngine2/zend.cTue Jun 1 07:45:46 2004
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */
+/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */
#include zend.h
#include zend_extensions.h
@@ -974,7 +974,7 @@
if (call_user_function_ex(CG(function_table), NULL,
orig_user_error_handler, retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) {
if (retval) {
- if (Z_TYPE_P(retval) != IS_NULL
!zend_is_true(retval)) {
+ if (Z_TYPE_P(retval) == IS_BOOL
Z_LVAL_P(retval) == 0) {
zend_error_cb(type, error_filename,
error_lineno, format, args);
}
zval_ptr_dtor(retval);
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I think it's OK to add.
At 09:26 AM 6/1/2004 -0700, Andrei Zmievski wrote:
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
andi Tue Jun 1 07:45:46 2004 EDT
Modified files:
/ZendEngine2 zend.c
Log:
- If user error handler returns false then we relay to the built in
error
handler
http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284r2=1.285ty=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285
--- ZendEngine2/zend.c:1.284 Fri May 28 13:28:33 2004
+++ ZendEngine2/zend.cTue Jun 1 07:45:46 2004
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */
+/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */
#include zend.h
#include zend_extensions.h
@@ -974,7 +974,7 @@
if (call_user_function_ex(CG(function_table),
NULL, orig_user_error_handler, retval, 5, params, 1, NULL
TSRMLS_CC)==SUCCESS) {
if (retval) {
- if (Z_TYPE_P(retval) != IS_NULL
!zend_is_true(retval)) {
+ if (Z_TYPE_P(retval) == IS_BOOL
Z_LVAL_P(retval) == 0) {
zend_error_cb(type,
error_filename, error_lineno, format, args);
}
zval_ptr_dtor(retval);
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I'd like to see this in PHP4 too.
-Rasmus
On Tue, 1 Jun 2004, Andrei Zmievski wrote:
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
andiTue Jun 1 07:45:46 2004 EDT
Modified files:
/ZendEngine2zend.c
Log:
- If user error handler returns false then we relay to the built in error
handler
http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284r2=1.285ty=u
Index: ZendEngine2/zend.c
diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285
--- ZendEngine2/zend.c:1.284Fri May 28 13:28:33 2004
+++ ZendEngine2/zend.c Tue Jun 1 07:45:46 2004
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */
+/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */
#include zend.h
#include zend_extensions.h
@@ -974,7 +974,7 @@
if (call_user_function_ex(CG(function_table), NULL,
orig_user_error_handler, retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) {
if (retval) {
- if (Z_TYPE_P(retval) != IS_NULL
!zend_is_true(retval)) {
+ if (Z_TYPE_P(retval) == IS_BOOL
Z_LVAL_P(retval) == 0) {
zend_error_cb(type, error_filename,
error_lineno, format, args);
}
zval_ptr_dtor(retval);
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
On 2003/12/20, at 0:21, Dmitry Stogov wrote: Hi Moriyoshi, Yes I am sure. Andi approved this patch today. I didn't know about your patch. May be you know some situations when my patch will not work properly? As far as I looked over the patch, your patch appears the right fix for the problem. I asked you it because I was told by Andi that the garbage collection is sensitive stuff and handled with extreme care. Actually I think nothing will be wrong with it. However, I suspect that we don't need to replicate the same garbage collecting code to that place. I think all we have to do is delay the GC timing so it would be performed after the error handler is executed. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
On 2003/12/20, at 1:36, Dmitry Stogov wrote:
I do GC after error_handler execution, because GC stack has limited
size
and if I will try to link old garbage with garbage from error_handler I
can overflow it.
Okay, so it seems my patch was not sufficient as it's still possible
GC stack will overflow.
Then, could you take a look at the 4.3 branch also? It still seems
to have the same problem as HEAD. Besides operations on undefined object
properties lead to the same situation with ZE1. (I wasn't able to
verify it with ZE2.)
?php
function custom_err_hdlr($errno, $errstr, $errfile, $errline, $context)
{
echo __FUNCTION__ . ($errstr)\n;
}
function foo($x) { return foo; }
set_error_handler('custom_err_hdlr');
$a-b[foo(bar)]++;
?
With the above snippet, valgrind reported the following leaks:
==2279== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==2279== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==2279== Using valgrind-2.0.0, a program supervision framework for
x86-linux.
==2279== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==2279== Estimated CPU clock rate is 1001 MHz
==2279== For more details, rerun with: -v
==2279==
==2279== Conditional jump or move depends on uninitialised value(s)
==2279==at 0x40009520: _dl_relocate_object (in /lib/ld-2.3.2.so)
==2279==by 0x407E1E25: (within /lib/libc-2.3.2.so)
==2279==by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==2279==by 0x407E20A8: _dl_open (in /lib/libc-2.3.2.so)
==2279==
==2279== Conditional jump or move depends on uninitialised value(s)
==2279==at 0x40009575: _dl_relocate_object (in /lib/ld-2.3.2.so)
==2279==by 0x407E1E25: (within /lib/libc-2.3.2.so)
==2279==by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so)
==2279==by 0x407E20A8: _dl_open (in /lib/libc-2.3.2.so)
==2279==
==2279== Invalid read of size 1
==2279==at 0x81CCB53: zend_hash_add_or_update (zend_hash.c:238)
==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner
(zend_execute.c:648)
==2279==by 0x81D6BEA: zend_fetch_dimension_address
(zend_execute.c:787)
==2279==by 0x81D8A3B: execute (zend_execute.c:1290)
==2279==Address 0x42334F14 is 36 bytes inside a block of size 48
free'd
==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310)
==2279==by 0x81B6662: _erealloc (zend_alloc.c:323)
==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017)
==2279==by 0x81D9C1D: execute (zend_execute.c:1483)
==2279==
==2279== Invalid read of size 1
==2279==at 0x81CCB5E: zend_hash_add_or_update (zend_hash.c:238)
==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner
(zend_execute.c:648)
==2279==by 0x81D6BEA: zend_fetch_dimension_address
(zend_execute.c:787)
==2279==by 0x81D8A3B: execute (zend_execute.c:1290)
==2279==Address 0x42334F14 is 36 bytes inside a block of size 48
free'd
==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310)
==2279==by 0x81B6662: _erealloc (zend_alloc.c:323)
==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017)
==2279==by 0x81D9C1D: execute (zend_execute.c:1483)
==2279==
==2279== Invalid read of size 1
==2279==at 0x81CFE99: zend_inline_hash_func (zend_hash.h:198)
==2279==by 0x81CCCA4: zend_hash_add_or_update (zend_hash.c:240)
==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner
(zend_execute.c:648)
==2279==by 0x81D6BEA: zend_fetch_dimension_address
(zend_execute.c:787)
==2279==Address 0x42334F14 is 36 bytes inside a block of size 48
free'd
==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310)
==2279==by 0x81B6662: _erealloc (zend_alloc.c:323)
==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017)
==2279==by 0x81D9C1D: execute (zend_execute.c:1483)
==2279==
==2279== Invalid read of size 1
==2279==at 0x4002433F: memcpy (mac_replace_strmem.c:258)
==2279==by 0x81CCF57: zend_hash_add_or_update (zend_hash.c:276)
==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner
(zend_execute.c:648)
==2279==by 0x81D6BEA: zend_fetch_dimension_address
(zend_execute.c:787)
==2279==Address 0x42334F17 is 39 bytes inside a block of size 48
free'd
==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310)
==2279==by 0x81B6662: _erealloc (zend_alloc.c:323)
==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017)
==2279==by 0x81D9C1D: execute (zend_execute.c:1483)
==2279==
==2279== Invalid read of size 1
==2279==at 0x40024346: memcpy (mac_replace_strmem.c:259)
==2279==by 0x81CCF57: zend_hash_add_or_update (zend_hash.c:276)
==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner
(zend_execute.c:648)
==2279==by 0x81D6BEA: zend_fetch_dimension_address
(zend_execute.c:787)
==2279==Address 0x42334F16 is 38 bytes inside a block of size 48
free'd
==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310)
==2279==by 0x81B6662: _erealloc (zend_alloc.c:323)
==2279==by 0x81C44B7: add_string_to_string
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
At 12:54 AM 12/20/2003 +0900, Moriyoshi Koizumi wrote: On 2003/12/20, at 0:21, Dmitry Stogov wrote: Hi Moriyoshi, Yes I am sure. Andi approved this patch today. I didn't know about your patch. May be you know some situations when my patch will not work properly? As far as I looked over the patch, your patch appears the right fix for the problem. I asked you it because I was told by Andi that the garbage collection is sensitive stuff and handled with extreme care. Actually I think nothing will be wrong with it. However, I suspect that we don't need to replicate the same garbage collecting code to that place. I think all we have to do is delay the GC timing so it would be performed after the error handler is executed. Just to explain in a bit more detail, your atomic postponing of garbage collecting isn't good because too much can accumulate and/or the life time of garbage could be too long. I think Dmitry's patch handles this slightly in a different way and better although as I said, a thorough fix should be done. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
At 23:00 05/06/2003, Sebastian Bergmann wrote: Zeev Suraski wrote: It does look like a voodoo fix. What's crashing exactly? Zeev, Stanislav already looked into this and the segfault related to GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone. But with a fairly odd fix. When was it crashing, prior to that fix? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Zeev Suraski wrote: It does look like a voodoo fix. What's crashing exactly? Zeev, Stanislav already looked into this and the segfault related to GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ http://www.professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Thies C. Arntzen wrote: i trust you;-) but - after looking thru zend.c - i think that the TLS stuff is getting more and more un-maintainable. What really looks messed up is #ifdef ZTS ... #ifdef ZTS ... #else ... #endif ... #endif -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
At 15:43 04.06.2003, Sebastian Bergmann wrote: Thies C. Arntzen wrote: i trust you;-) but - after looking thru zend.c - i think that the TLS stuff is getting more and more un-maintainable. What really looks messed up is #ifdef ZTS ... #ifdef ZTS ... #else ... #endif ... #endif And there is really no reson for. Really not. marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Marcus Börger wrote: So he should be forgiven if he doesn't try all version. Marcus, Derick, *, relax. Don't defend me, as I feel not offended. For the first time I did not test a non-ZTS build before committing a ZTS fix, so it was a mistake on my side. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
On Wed, 4 Jun 2003, Sebastian Bergmann wrote: Marcus Börger wrote: So he should be forgiven if he doesn't try all version. Marcus, Derick, *, relax. Don't defend me, as I feel not offended. For the first time I did not test a non-ZTS build before committing a ZTS fix, so it was a mistake on my side. Hi Sebastian, I found Stanislav's comments offensive no matter that they were sent to you. My guess other people felt offended by that attitude as well. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Stanislav Malyshev wrote: _explain_ what you are doing instead of submitting patched that don't even compile? It compiles fine here (Debug_TS build on Windows). Without that patch it compiles as well, but segfaults during startup. See http://news.php.net/article.php?group=php.internalsarticle=2125 for a backtrace and http://news.php.net/article.php?group=php.internalsarticle=2136 for its analysis (GLOBAL_CONSTANTS_TABLE is not malloced). -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
