Re: [PHP-DEV] Zend Constants PATCH
Andi Gutmans wrote: Hi, I'll try and get the patch into PHP soon (I was busy with other things) I want to rewrite it a bit to make it nicer. does the case-sensitive, then case-insensitive logic really make that much sense? wouldn't it be easier *and* more consistent to make zend_str_tolower() not use libc tolower() but some locale-insensitive code instead? or am i missing something? btw, the use of strtod() within the engine is a similar problem the lexer always looks for '.' as decimal_point (which is right) but then uses strtod() to convert the found string into a double without taking in account that the decimal_point in the current locale may be a different character so that parsing stops at the '.', cutting off all decimals so strtod() should be replaced by something not locale-aware (and no, atof() is not what we are looking for) or replace the '.' with whatever decimal_point is set to in the current locale first solution would perform better, but from looking at the OpenBSD implementation of strtod() i think the second has far less potential for problems while not performing to bad if decimal_point is cached somehow ... PS: IMHO we have to rethink the complete set_locale() stuff in PHP as there is absolutely no way to make it work in threaded SAPIs :( -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
On June 18, 2002 05:32 am, Hartmut Holzgraefe wrote: Andi Gutmans wrote: Hi, I'll try and get the patch into PHP soon (I was busy with other things) I want to rewrite it a bit to make it nicer. does the case-sensitive, then case-insensitive logic really make that much sense? wouldn't it be easier *and* more consistent to make zend_str_tolower() not use libc tolower() but some locale-insensitive code instead? or am i missing something? btw, the use of strtod() within the engine is a similar problem the lexer always looks for '.' as decimal_point (which is right) but then uses strtod() to convert the found string into a double without taking in account that the decimal_point in the current locale may be a different character so that parsing stops at the '.', cutting off all decimals so strtod() should be replaced by something not locale-aware (and no, atof() is not what we are looking for) or replace the '.' with whatever decimal_point is set to in the current locale first solution would perform better, but from looking at the OpenBSD implementation of strtod() i think the second has far less potential for problems while not performing to bad if decimal_point is cached somehow ... By using a functiont that does not support lowercasing, would also cause problems, since if a constant name contains non english characters it would break. IMHO the best implementation is to simply not lowercase constant names unless the user specifically whats case insensetive locale. PS: IMHO we have to rethink the complete set_locale() stuff in PHP as there is absolutely no way to make it work in threaded SAPIs :( Doesn't work, simply not true. My PHP code uses locales extensively and it works just fine on Apache 2.0 (threads model) and on IIS, which uses threads. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia A. wrote: By using a functiont that does not support lowercasing, would also cause problems, since if a constant name contains non english characters it would break. IMHO the best implementation is to simply not lowercase constant names unless the user specifically whats case insensetive locale. the language parser should not be affected by locale settings at all, so we need a locale independant zend_str_tolower() function or make sure we have 'C' or 'POSIX' locale this does not only affect constants but also function names and unless we are going to roll up the complete case sensitivity threads *again* rolling our own tolower() function instead of using the one in libc is the only way to go IMHO PS: IMHO we have to rethink the complete set_locale() stuff in PHP as there is absolutely no way to make it work in threaded SAPIs :( Doesn't work, simply not true. My PHP code uses locales extensively and it works just fine on Apache 2.0 (threads model) and on IIS, which uses threads. ok, bad wording Sure set_locale() *works* for threaded environments, but it sets the locale globaly for *all* threads, while it should the current PHP thread only. Even worse: setting the locale may affect other components within the webserver totally unrelated to PHP (or trigger the now known tolower() and strtod() problems in other PHP threads, leading to wrong parser behaviour) just imagine an ISP hosting a threaded server for international customers or a big multinational company (or even a small one with multi-lingual web pages) where a lot of scripts running in parallel use set_locale() - each of them overwrites the current locale for all the other runnning scripts ... GOTCHA -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia A. wrote: Well, that is true for any external variable not just locale. For example if you export TZ variable in a threaded enviroment all threads would be affected. Exporting a TZ would be even more dangerous since it would affect a commonly used data, dates, which are used in majority of PHP script. messing around with the process environment is one thing, using an official PHP function is a different story ... I do not see how this issue can be resolved, unless PHP does some internal enviroment variable tracking as well as internal locale tracking. environment variable tracking is not needed, PHP has just to implement its own versions of locale dependant functions, track requested locale internaly as a thread variable and leave the global locale setting alone there are about 20 functions that need changes applied, most of them just use toupper()/tolower() or ctype is***() functions which can easily be replaced only things like printf(), scanf() and strftime() are a bit more difficult. For printf() and scanf() we already have our own versions that we just need to modify, and for strftime() we should bundle our own version anyway, as there are way to much problems with esp. windows users not knowing (and not reading in the docs) that not all of strftime()'s format placeholders work in every strftime() implementation i've already assigned this to me as a task for this weekend, maybe i'll find time to publish a small RFC/Whitepaper about the issues at hand tomorrow (detailed description of planned changes, affected functions, list of bugs that will be solved by the changes ...) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 H.A.R.T.M.U.T.: Hydraulic Artificial Replicant Trained for Mathematics and Ultimate Troubleshooting -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Well, that is true for any external variable not just locale. For example if you export TZ variable in a threaded enviroment all threads would be affected. Exporting a TZ would be even more dangerous since it would affect a commonly used data, dates, which are used in majority of PHP script. I do not see how this issue can be resolved, unless PHP does some internal enviroment variable tracking as well as internal locale tracking. Uh, it does. (env var tracking) -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
At 04:07 PM 6/18/2002 +0200, Hartmut Holzgraefe wrote: Ilia A. wrote: By using a functiont that does not support lowercasing, would also cause problems, since if a constant name contains non english characters it would break. IMHO the best implementation is to simply not lowercase constant names unless the user specifically whats case insensetive locale. the language parser should not be affected by locale settings at all, so we need a locale independant zend_str_tolower() function or make sure we have 'C' or 'POSIX' locale Right. For example, decimal's in PHP use a . (e.g. 3.14). This should always be the case even if the locale uses a different separator like , in German. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Hey,
Please test the attached patch and let me know if it works for you.
I haven't really had the chance to test it too much.
Andi
At 06:21 PM 6/15/2002 -0400, Ilia A. wrote:
Andi,
I wrote another patch, this time a 'proper' way, which means the old
functionality of case insensetivity is supported. Please look it over,
hopefuly this is good enough to commit.
I've also attached a small php test script you can use to see the problem in
non patched PHPs.
Ilia
On June 15, 2002 03:25 pm, Andi Gutmans wrote:
Ilia,
I remember now the problem you're talking about. It has been discussed here
in the past and I don't recall us having found a good solution. Basically
we need a solution which is backwards compatible but will allow TEST and
test to co-exist if case sensitivity was chosen for them.
It's something to think about and not create a quick 2 line patch for the
problem. I think one of the suggestions was using two hash tables. First
doing a case-sensitive lookup and only if the constant isn't found doing a
case-insensitive lookup.
Andi
At 03:40 PM 6/15/2002 -0400, Ilia A. wrote:
Andi,
Yes, you are correct in that respect, my patch would accomplish just that.
No where in PHP documentation does it say that you cannot have TEST and
test defines in the same script. Unless you specifically tell the
define() function to treat the define as case insensitive.
Because the defines are always lowercased unless the defines for i18n
systems are always declared in lower case any define with a letter 'I'
for example would break on a system using most non English locales. This
is a VERY serious problems, for example consider the reversal of the
htmlenteties() function. The following code:
get_html_translation_table (HTML_ENTITIES);
will break if a ru_UI or tr_TR or any other number of non-English locales
are exported.
In addition because all locales are lower cased defines suffer large
performance degradation when compared to other variables because another
copy of the define name needs to be allocated and then lower cased every
single time a define is declared or retrieved.
As far as I know, php variables are always case sensitive and there is now
way
to make them not, why an exception was made for defines I do not know,
especially when you consider that in C and C++ defines are ALWAYS case
sensitive. IMHO this is a very bad feature, that not only implements
useless functionality but actually causes PHP code to break.
Therefor, I humbly ask that you reconsider your position on this issue.
Ilia
On June 15, 2002 03:03 pm, you wrote:
Ilia,
Your patch basically makes PHP constants case sensitive.
Changing this is a very big backwards compatibility problem.
You're not supposed to register two define's with the same letters but
different case.
Andi
At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
Hello,
While developing software in PHP that supports i18n I've come across
several problems that affect defines made in PHP.
The first problem is that when a define is declared and its name
contains upper case characters such as I, the define becomes unusable
if a locale, which does not support those chracters is exported, such
as tr_TR or ru_IU. Bug Report at:
http://bugs.php.net/bug.php?id=16865
There is a problem with case sensetivity of defines, for example, if
you create a case sensetive define 'TEST' and then a case sensetive
define 'test', the latter define's value will be lost.
Bug Report at: http://bugs.php.net/?id=17658
The problem occurs because zend internally (zend_constants.c) seems to
always lowecase the define before it is fetched/added to the hash
table of defines. This causes problem for i18n because the define is
lowercased using c's tolower function, which is affected by locale
settings. Because it is stored as lower case, having 2 defines with
the same name but in different case also becomes impossible to do.
Attached is a patch against zend_constants.c CVS revision 1.38 that
fixes both
of these bugs, I hope the developers would consider adding this patch
to the CVS.
Ilia
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: zend_constants.c
===
RCS file: /repository/ZendEngine2/zend_constants.c,v
retrieving revision 1.39
diff -u -r1.39 zend_constants.c
--- zend_constants.c6 Jan 2002 15:21:35 - 1.39
+++ zend_constants.c18 Jun 2002 19:10:38 -
-220,26 +220,27
{
zend_constant *c;
char *lookup_name;
- int retval;
+ int retval = 1;
- lookup_name = do_alloca(name_len+1);
- memcpy(lookup_name, name, name_len+1);
-
-
[PHP-DEV] Zend Constants PATCH
Hello,
While developing software in PHP that supports i18n I've come across several
problems that affect defines made in PHP.
The first problem is that when a define is declared and its name contains
upper case characters such as I, the define becomes unusable if a locale,
which does not support those chracters is exported, such as tr_TR or ru_IU.
Bug Report at: http://bugs.php.net/bug.php?id=16865
There is a problem with case sensetivity of defines, for example, if you
create a case sensetive define 'TEST' and then a case sensetive define
'test', the latter define's value will be lost.
Bug Report at: http://bugs.php.net/?id=17658
The problem occurs because zend internally (zend_constants.c) seems to always
lowecase the define before it is fetched/added to the hash table of defines.
This causes problem for i18n because the define is lowercased using c's
tolower function, which is affected by locale settings. Because it is stored
as lower case, having 2 defines with the same name but in different case also
becomes impossible to do.
Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both
of these bugs, I hope the developers would consider adding this patch to the
CVS.
Ilia
--- zend_constants.c_old Sat Jun 15 13:02:40 2002
+++ zend_constants.c Sat Jun 15 12:59:11 2002
-226,8 +226,6
lookup_name = do_alloca(name_len+1);
memcpy(lookup_name, name, name_len+1);
- zend_str_tolower(lookup_name, name_len);
-
if (zend_hash_find(EG(zend_constants), lookup_name, name_len+1, (void **) c)==SUCCESS) {
if ((c-flags CONST_CS) memcmp(c-name, name, name_len)!=0) {
retval=0;
-255,7 +253,6
printf(Registering constant for module %d\n, c-module_number);
#endif
- zend_str_tolower(lowercase_name, c-name_len);
if (zend_hash_add(EG(zend_constants), lowercase_name, c-name_len, (void *) c, sizeof(zend_constant), NULL)==FAILURE) {
free(c-name);
if (!(c-flags CONST_PERSISTENT)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
What about a configuration option in php.ini use_case_sensitive = 0|1 and let it be 0 as default ? On Sat, 15 Jun 2002 22:25:18 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
We're not going to add configuration options which change the language's behavior! We've said this a million times. Andi At 09:41 PM 6/15/2002 +0200, Magnus M wrote: What about a configuration option in php.ini use_case_sensitive = 0|1 and let it be 0 as default ? On Sat, 15 Jun 2002 22:25:18 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
ok, sorry.. Missed that one.. On Sat, 15 Jun 2002 22:44:24 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: We're not going to add configuration options which change the language's behavior! We've said this a million times. Andi At 09:41 PM 6/15/2002 +0200, Magnus M wrote: What about a configuration option in php.ini use_case_sensitive = 0|1 and let it be 0 as default ? On Sat, 15 Jun 2002 22:25:18 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Andi,
I wrote another patch, this time a 'proper' way, which means the old
functionality of case insensetivity is supported. Please look it over,
hopefuly this is good enough to commit.
I've also attached a small php test script you can use to see the problem in
non patched PHPs.
Ilia
On June 15, 2002 03:25 pm, Andi Gutmans wrote:
Ilia,
I remember now the problem you're talking about. It has been discussed here
in the past and I don't recall us having found a good solution. Basically
we need a solution which is backwards compatible but will allow TEST and
test to co-exist if case sensitivity was chosen for them.
It's something to think about and not create a quick 2 line patch for the
problem. I think one of the suggestions was using two hash tables. First
doing a case-sensitive lookup and only if the constant isn't found doing a
case-insensitive lookup.
Andi
At 03:40 PM 6/15/2002 -0400, Ilia A. wrote:
Andi,
Yes, you are correct in that respect, my patch would accomplish just that.
No where in PHP documentation does it say that you cannot have TEST and
test defines in the same script. Unless you specifically tell the
define() function to treat the define as case insensitive.
Because the defines are always lowercased unless the defines for i18n
systems are always declared in lower case any define with a letter 'I'
for example would break on a system using most non English locales. This
is a VERY serious problems, for example consider the reversal of the
htmlenteties() function. The following code:
get_html_translation_table (HTML_ENTITIES);
will break if a ru_UI or tr_TR or any other number of non-English locales
are exported.
In addition because all locales are lower cased defines suffer large
performance degradation when compared to other variables because another
copy of the define name needs to be allocated and then lower cased every
single time a define is declared or retrieved.
As far as I know, php variables are always case sensitive and there is now
way
to make them not, why an exception was made for defines I do not know,
especially when you consider that in C and C++ defines are ALWAYS case
sensitive. IMHO this is a very bad feature, that not only implements
useless functionality but actually causes PHP code to break.
Therefor, I humbly ask that you reconsider your position on this issue.
Ilia
On June 15, 2002 03:03 pm, you wrote:
Ilia,
Your patch basically makes PHP constants case sensitive.
Changing this is a very big backwards compatibility problem.
You're not supposed to register two define's with the same letters but
different case.
Andi
At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
Hello,
While developing software in PHP that supports i18n I've come across
several problems that affect defines made in PHP.
The first problem is that when a define is declared and its name
contains upper case characters such as I, the define becomes unusable
if a locale, which does not support those chracters is exported, such
as tr_TR or ru_IU. Bug Report at:
http://bugs.php.net/bug.php?id=16865
There is a problem with case sensetivity of defines, for example, if
you create a case sensetive define 'TEST' and then a case sensetive
define 'test', the latter define's value will be lost.
Bug Report at: http://bugs.php.net/?id=17658
The problem occurs because zend internally (zend_constants.c) seems to
always lowecase the define before it is fetched/added to the hash
table of defines. This causes problem for i18n because the define is
lowercased using c's tolower function, which is affected by locale
settings. Because it is stored as lower case, having 2 defines with
the same name but in different case also becomes impossible to do.
Attached is a patch against zend_constants.c CVS revision 1.38 that
fixes both
of these bugs, I hope the developers would consider adding this patch
to the CVS.
Ilia
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
?php
define('TEST', TEST #1);
define('test', test #2);
echo TEST.\n;
echo test.\n;
/* User case define */
define('NO_CASE', 'case insensetive constant', TRUE);
echo NO_CASE.\n;
echo no_case.\n;
echo No_CaSe.\n;
/* PHP Made case Defines */
echo TRUE.\n;
echo trUe.\n;
echo TrUe.\n;
/* I18n test */
define('iii', 'i18n');
setlocale('LC_ALL', 'tr_TR');
echo iii.\n;
?
--- zend_constants.c_old Sat Jun 15 17:46:53 2002
+++ zend_constants.c Sat Jun 15 18:09:59 2002
-222,12 +222,12
zend_constant *c;
char *lookup_name;
int retval;
-
- lookup_name = do_alloca(name_len+1);
- memcpy(lookup_name, name, name_len+1);
-
- zend_str_tolower(lookup_name, name_len);
-
+ int c_flag;
+
+ c_flag=1;
+ lookup_name = name;
+
+ casechk:
if (zend_hash_find(EG(zend_constants), lookup_name,
