#35583 [Bgs]: Calling user defined functions after setlocale(tr_TR) produces errors
ID: 35583 User updated by: sezai dot yilmaz at pro-g dot com dot tr Reported By: sezai dot yilmaz at pro-g dot com dot tr Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian GNU/Linux 2.6.12 PHP Version: 5.1.1 New Comment: Bug related with the same problem has been submitted first at 2002 year. Over 3 years is passed, but the bug still affects our multilingual projects. Because of that I prefer to resubmit the new one with more generic description. The problem is not related with only constants or classes (like the previous related bug reports describe). It affects all incasesensitive staff like constant names, class names, method names. function names... Previous Comments: [2005-12-07 17:08:23] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. [2005-12-07 15:21:53] sezai dot yilmaz at pro-g dot com dot tr Description: This bug has duplicates with status closed here (for example #18556). But the problem is still continue to survive in the latest PHP. The problem is case insensitive function name handling in PHP's scripting engine and the native behavior of Turkish language. Turkish language has a letter I of which the lowercase is dotless i (#305;). PHP engine itself running on different locale lowercases and registers user defined functions with its running environment's locale. But while parsing the user's PHP source code and the code itself has a call setlocale(LC_ALL, tr_TR) then the user defined functions are lowercased with Turkish locale. If the function name contains the letter I then it is never matched with the previously registered lowercased one. For example getImageDir() is registered as getimagedir() but with Turkish locale set by user code it is compared with get#305;magedir() and the results is undefined function. I think this is a developer bug because of using locale aware functions for lowercasing native english keywords. The problem affects function names, class names, method names, ... all incasesensitive staff. And all of them have to be native English. I made a solution by modifying the source file php-5.1.1/Zend/zend_operators.c. Instead of using the locale aware tolower(int) libc function in zend_str_tolower(), zend_str_tolower_copy() functions, I I wrote down a tolower_english(int) equivalent to tolower() and called it in zend_str_tolower() / zend_str_tolower() instead of the original one tolower(). Function names, class names, method names are not locale aware staff, so why to use locale aware tolower() libc function? Function names, class names, method names are natively in English locale, aren't they? I don't understand why developers use locale aware functions for native english keywords like function names, class names, method names, ... etc. I am tired of patching the PHP code with my non-perfect solution. Reproduce code: --- My solution is not perfect, it may cause unexpected problems. But I use it without problems until now. It is better to use strictly English locale functions instead of locale aware one for collating natively English strings. http://www.pro-g.com.tr/php_turkish_bug/zend_operators.c.diff -- Edit this bug report at http://bugs.php.net/?id=35583edit=1
#35583 [NEW]: Calling user defined functions after setlocale(tr_TR) produces errors
From: sezai dot yilmaz at pro-g dot com dot tr Operating system: Debian GNU/Linux 2.6.12 PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: Calling user defined functions after setlocale(tr_TR) produces errors Description: This bug has duplicates with status closed here (for example #18556). But the problem is still continue to survive in the latest PHP. The problem is case insensitive function name handling in PHP's scripting engine and the native behavior of Turkish language. Turkish language has a letter I of which the lowercase is dotless i (#305;). PHP engine itself running on different locale lowercases and registers user defined functions with its running environment's locale. But while parsing the user's PHP source code and the code itself has a call setlocale(LC_ALL, tr_TR) then the user defined functions are lowercased with Turkish locale. If the function name contains the letter I then it is never matched with the previously registered lowercased one. For example getImageDir() is registered as getimagedir() but with Turkish locale set by user code it is compared with get#305;magedir() and the results is undefined function. I think this is a developer bug because of using locale aware functions for lowercasing native english keywords. The problem affects function names, class names, method names, ... all incasesensitive staff. And all of them have to be native English. I made a solution by modifying the source file php-5.1.1/Zend/zend_operators.c. Instead of using the locale aware tolower(int) libc function in zend_str_tolower(), zend_str_tolower_copy() functions, I I wrote down a tolower_english(int) equivalent to tolower() and called it in zend_str_tolower() / zend_str_tolower() instead of the original one tolower(). Function names, class names, method names are not locale aware staff, so why to use locale aware tolower() libc function? Function names, class names, method names are natively in English locale, aren't they? I don't understand why developers use locale aware functions for native english keywords like function names, class names, method names, ... etc. I am tired of patching the PHP code with my non-perfect solution. Reproduce code: --- My solution is not perfect, it may cause unexpected problems. But I use it without problems until now. It is better to use strictly English locale functions instead of locale aware one for collating natively English strings. http://www.pro-g.com.tr/php_turkish_bug/zend_operators.c.diff -- Edit bug report at http://bugs.php.net/?id=35583edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35583r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35583r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35583r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35583r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35583r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35583r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35583r=needscript Try newer version:http://bugs.php.net/fix.php?id=35583r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35583r=support Expected behavior:http://bugs.php.net/fix.php?id=35583r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35583r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35583r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35583r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35583r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35583r=dst IIS Stability:http://bugs.php.net/fix.php?id=35583r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35583r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35583r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35583r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35583r=mysqlcfg
