Re-opening of bug #18556

[Michael Ditum-2]

Hi,

I came across a bug with classes when using a turkish locale. Looking at
the bug database the bug has existed for a while as #18556
(http://bugs.php.net/bug.php?id=18556).

The last entry on that bug was from September 2006 with the text...

No feedback was provided for this bug for over a week, so it is being
suspended automatically. If you are able to provide the information that
was originally requested, please do so and change the status of the bug
back to "Open".

I've added a comment stating that I can still recreate the listed bug
and added some extra information however as I am not owner of the bug I
cannot change the status of the bug to "Open". Could someone re-open the
bug for me?

I am more than happy to take ownership of the bug and provide testing of
any cvs snapshots in the future.

Thanks for your help!

Mike

p.s. I've just tested snapshot php5.2-200707171230 and can confirm the
issue still exists.

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Johannes Schlüter-3]

Hi Michael,

there are also other reports an this issue. The Problem is the capital
"I" with the fact that strtolower("I") != "i" in a tr_TR locale. This
will change with PHP 6's Unicode mode but won't change with PHP 5. As
work-around use "i" instead of "I" in the names.

johannes

On Tue, 2007-07-17 at 14:28 +0100, Michael Ditum wrote:

> Hi,
>
> I came across a bug with classes when using a turkish locale. Looking at
> the bug database the bug has existed for a while as #18556
> (http://bugs.php.net/bug.php?id=18556).
>
> The last entry on that bug was from September 2006 with the text...
>
> No feedback was provided for this bug for over a week, so it is being
> suspended automatically. If you are able to provide the information that
> was originally requested, please do so and change the status of the bug
> back to "Open".
>
> I've added a comment stating that I can still recreate the listed bug
> and added some extra information however as I am not owner of the bug I
> cannot change the status of the bug to "Open". Could someone re-open the
> bug for me?
>
> I am more than happy to take ownership of the bug and provide testing of
> any cvs snapshots in the future.
>
> Thanks for your help!
>
> Mike
>
> p.s. I've just tested snapshot php5.2-200707171230 and can confirm the
> issue still exists.

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Wil Clouser]

I've run into this issue with Turkish before too.  The issue is with
using LC_ALL (or, more specifically LC_CTYPE through the use of
LC_ALL).  The documentation says "The LC_CTYPE category shall define
character classification, case conversion, and other character
attributes." [1] but it also specifically includes a standard set of
characters. including an uppercase 'I'.  It sounds, to me, like that
set of characters is getting changed/corrupted for Turkish and the
other locales you mentioned somewhere in the code.

Anyway, it's not a fix for the bug, but if you need to get something
on your site working now, you can skip setting LC_CTYPE and just call
setlocale() for each of the other LC_* variables.

Wil

[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html

On 7/17/07, Michael Ditum <mike.ditum@...> wrote:

> Hi,
>
> I came across a bug with classes when using a turkish locale. Looking at
> the bug database the bug has existed for a while as #18556
> (http://bugs.php.net/bug.php?id=18556).
>
> The last entry on that bug was from September 2006 with the text...
>
> No feedback was provided for this bug for over a week, so it is being
> suspended automatically. If you are able to provide the information that
> was originally requested, please do so and change the status of the bug
> back to "Open".
>
> I've added a comment stating that I can still recreate the listed bug
> and added some extra information however as I am not owner of the bug I
> cannot change the status of the bug to "Open". Could someone re-open the
> bug for me?
>
> I am more than happy to take ownership of the bug and provide testing of
> any cvs snapshots in the future.
>
> Thanks for your help!
>
> Mike
>
> p.s. I've just tested snapshot php5.2-200707171230 and can confirm the
> issue still exists.
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Tomas Kuliavas]

Michael Ditum rašė:

> Hi,
>
> I came across a bug with classes when using a turkish locale. Looking at
> the bug database the bug has existed for a while as #18556
> (http://bugs.php.net/bug.php?id=18556).
>
> The last entry on that bug was from September 2006 with the text...
>
> No feedback was provided for this bug for over a week, so it is being
> suspended automatically. If you are able to provide the information that
> was originally requested, please do so and change the status of the bug
> back to "Open".
>
> I've added a comment stating that I can still recreate the listed bug
> and added some extra information however as I am not owner of the bug I
> cannot change the status of the bug to "Open". Could someone re-open the
> bug for me?
>
> I am more than happy to take ownership of the bug and provide testing of
> any cvs snapshots in the future.
>
> Thanks for your help!
>
> Mike
>
> p.s. I've just tested snapshot php5.2-200707171230 and can confirm the
> issue still exists.

Maybe issue does not exists, but was reintroduced by some programmer.
Turkish, Azerbaijani and Kurdish languages can create lots of issues, if
programmer uses locale aware case insensitive comparison functions to
compare ASCII strings. I think PHP does not have string functions that
are executed in LC_CTYPE=C. That's why Turkish bugs pop out from time to
time.

--
Tomas

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Tomas Kuliavas]

> there are also other reports an this issue. The Problem is the capital
> "I" with the fact that strtolower("I") != "i" in a tr_TR locale. This
> will change with PHP 6's Unicode mode but won't change with PHP 5. As
> work-around use "i" instead of "I" in the names.

Which part breaks if you fix zend_tolower() function? It is already
locale insensitive on Windows.

I've checked PHP5.2 and 6 snapshots compiled with './configure
--prefix=/some/path --with-config-file-path=/some/path'

'make test' does not show new issues.

In PHP6-200708151230 fixed interpreter lost 3% of performance in 'make
test' and 6% in Zend/bench.php tests. Fixed PHP5.2-200708211630 and
PHP6-200708211630 are even a bit faster on 'make test' and Zend/bench.php.

--
Tomas

--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php