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 s
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
>>co
> 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 scrip
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 maj
On June 18, 2002 10:07 am, Hartmut Holzgraefe wrote:
> 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 u
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 inse
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
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_tolo
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 Jun
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
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
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 recal
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'
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 defin
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 softwa
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 suppo
16 matches
Mail list logo
