Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/5/2012 12:22 AM, Galen Wright-Watson wrote: That also ran without error for me. I'm not sure how to account for the different behavior. Here are the details of the system that I'm using: $ uname -a Linux n10 3.2.6mtv10 #1 SMP Wed Mar 14 06:22:06 PDT 2012 x86_64 GNU/Linux $ php -v PHP 5.2.17 with Suhosin-Patch 0.9.7 (cli) (built: May 3 2012 12:16:32) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH I've been experimenting with bare-bones PHP I've built from pristine sources so far. Don't you think you should do the same, in dealing with such a bug? Here's the top portion of my 'php -i' output: ~/proj$ php-5.2.17/sapi/cli/php -i|head -28 phpinfo() PHP Version = 5.2.17 System = Linux trvuntu 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:08:43 UTC 2012 i686 Build Date = May 4 2012 20:03:30 Configure Command = './configure' '--disable-all' '--enable-cli' '--enable-vld' Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /usr/local/lib Loaded Configuration File = (none) Scan this dir for additional .ini files = (none) additional .ini files parsed = (none) PHP API = 20041225 PHP Extension = 20060613 Zend Extension = 220060519 Debug Build = no Thread Safety = disabled Zend Memory Manager = enabled IPv6 Support = enabled Registered PHP Streams = php, file, data, http, ftp Registered Stream Socket Transports = tcp, udp, unix, udg Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/5/2012 7:01 PM, Wim Wisselink wrote:
Try to var_dump the setLocale and see if it return the specified locale
or just 'false'.
I thought he was way past that control. Anyway, a simple test should
suffice:
setlocale(LC_CTYPE, 'tr_TR') or exit('setlocale failed\n');
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
On Wed, May 2, 2012 at 5:23 AM, C.Koycan5...@gmail.com wrote:
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koycan5...@gmail.com wrote:
As of 5.3.0 this bug does not exist for function names. Only classes and
interfaces.
Turns out, if you cause a function to be called dynamically by (e.g.)
using
a variable function, the bug will surface.
?php
setlocale(LC_CTYPE, 'tr_TR');
function IJK() {}
# succeeds
IJK();
If literal function call precedes the function definition, that would fail
too in 5.2.17, but not in 5.3.0.
What has changed in this regard 5.2-5.3 ?
Do you mean something like the following?
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
setlocale(LC_CTYPE, 'en_US');
function IJK() {echo __FUNCTION__, \n;}
I couldn't get it to generate an error under PHP 5.2.17. What am I missing?
Try this with 5.2.17:
?php
setlocale(LC_CTYPE, 'tr_TR');
IJK();
function IJK() {}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koycan5...@gmail.com wrote:
As of 5.3.0 this bug does not exist for function names. Only classes and
interfaces.
Turns out, if you cause a function to be called dynamically by (e.g.) using
a variable function, the bug will surface.
?php
setlocale(LC_CTYPE, 'tr_TR');
function IJK() {}
# succeeds
IJK();
If literal function call precedes the function definition, that would
fail too in 5.2.17, but not in 5.3.0.
What has changed in this regard 5.2-5.3 ?
$f = 'IJK';
# causes Fatal error: Call to undefined function IJK()
$f();
In contrast, if you set the locale for LC_CTYPE on the command line, the
bug doesn't arise at all because the compilation and execution phases both
use the same locale.
So, the bug also arises if a script started in 'tr_TR' env locale sets
its locale to 'en_US' at runtime.
[...]
I like the idea of using the system default locale for name conversion
(making name resolution independent of the current locale), but am
As I stated above, the locale the script was started in may not always
be 'en_US' or 'C'. (assuming that's what you mean by system default
locale)
By the way, I noticed a setlocale(LC_CTYPE, ) call in
php_module_startup()/main.c, but can't figure if it has any relevance to
this bug.
regards,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
Hi, As of 5.3.0 this bug does not exist for function names. Only classes and interfaces. Could this be a clue for how to fix it for those as well? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/22/2012 11:32 PM, Galen Wright-Watson wrote: 2012/4/22 C.Koycan5...@gmail.com On 4/21/2012 4:37 AM, Galen Wright-Watson wrote: But, I did not start this thread to discuss such bug fix, because: 1. It does not take a genius to figure it out, and should take minutes to implement for someone experienced in the internals. Given the 10 year span and dozens of comments/complaints on the bug's entry, it's hard to say this issue went unnoticed. So I had to conclude that such fix has quietly been overruled for performance and/or other undisclosed reasons. Why does it matter if a solution is simple? It doesn't matter, you've misunderstood. On the contrary, common sense dictates a simple solution should be applied (considering how deep in the PHP stack we're talking about). And that's what makes me curious and confused about why this bug still exists. See, I'm drawing a conclusion with what little information I have, and stating the reasonings it's based on (first two statements). Overall, that and the item following it were an explanation of why I'm suggesting a major feature change in solution to a specific bug, although noone directly asked me to. If it's already been rejected privately, it's time to bring the reasons into the open (which is why I asked). If not, it should be considered publicly. A comment dated 2002-09-26 on bug's page states the bug is fixed. The next comment dated 2006-02-17 states it reappeared. I don't know who did what 10, 6 years ago but it's been revoked. Why? That was the main reason I deemed this bug not fixable, hence suggest other ways to resolve. The abstract property that makes a locale problematic is obvious. I was looking for specific locales, as they need to be identified for a complete solution. I'm not locale expert. Given the public complaints/bugs we can, in practice, assume this affects Turkish and Azerbaijani only. (I don't know about Kurdish) best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/21/2012 4:37 AM, Galen Wright-Watson wrote: What about instead creating a special-purpose Zend function to normalize class names (zend_normalize_class_name, or zend_classname_tolower)? This function would examine the current locale and, if it's a problematic one, convert the string to lower case on its own (calling zend_tolower on non-problematic characters). Alternatively, zend_normalize_class_name could switch LC_CTYPE to an appropriate locale (e.g. UTF-8; the locale could be determined at compile time), call zend_str_tolower_copy, then switch back before returning. Then, any appropriate function (e.g. zend_resolve_class_name, zend_lookup_class_ex, class_exists, class_alias) would call zend_normalize_class_name instead of zend_str_tolower_copy/ zend_str_tolower_dup. In plain words/pseudo-code, adding an if statement at a certain step should suffice, like: 1. lowercase the name; 2. if the effective locale is tr_XY, then replace every ı with i; 3. look up the name; For those who have nothing to do with Turkish locales, that should incur the overhead of an if condition only. But, I did not start this thread to discuss such bug fix, because: 1. It does not take a genius to figure it out, and should take minutes to implement for someone experienced in the internals. Given the 10 year span and dozens of comments/complaints on the bug's entry, it's hard to say this issue went unnoticed. So I had to conclude that such fix has quietly been overruled for performance and/or other undisclosed reasons. 2. Absent bug #18556, case-sensitive PHP has merits as I stated in other post and several people voiced opinions in favor. Case-sensitive PHP is worth considering. Does this bug pop-up for locales other than Turkish, Azerbaijani and Kurdish ? Theoretically, this problem occurs for any locales sharing a letter lowercase of which is different from each other's, and the PHP script changes its locale among these locales throughout its execution. best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Complete case-sensitivity in PHP
Hi, This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. As the recent comments on that page indicate, there's not a deterministic way to resolve this issue, apart from eliminating tolower() calls for function/class names during lookup. Hence totally case-sensitive PHP. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/20/2012 6:44 PM, Sherif Ramadan wrote: Its naming rules are a little bit inconsistent in that regard. I just don't see a point in making it completely locale aware. The fact that you can do soefunc() and SOMEFUNC() and still invoke the same function is a benefit. And I suppose for those using UTF-8 encoded function names it might be convenient to make them case-sensitive as well. I'm not going to argue that it's not. I'm just going to say that it doesn't seem to be a significant problem. The lowercase of a multi-byte character is not the lowercase of individual bytes comprising it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/20/2012 8:57 PM, Kris Craig wrote: Turkish localization notwithstanding (I confess that I know absolutely * nothing* about that lol), one possible use-case could be if you're including an external library/framework that contains a function with the same name but different case. I'm not sure how likely that is, mind you, but I can see that as one potential benefit. Either way, I guess my point is that the arguments for/against this seem to parallel the arguments for Windows-style fso case-insensitivity vs. Unix-style fso case-sensitivity. Java, C#, Python, Ruby... are all case-sensitive. This is not a feature to be (mis-)used so that one can have a function named myfunc() and MyFunc() in the same code base. Case-insensitive class/function/interface names is a confusion for everyone with non-PHP development experience. There's not a modern OO platform that defines an interface named 'IDispatch' and later allows it to be referenced as 'idispatch' or 'iDispatch'. And PHP is becoming more OO with every major release. Overall, full case-sensitivity seems to be a natural step in PHP's evolution. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/20/2012 9:48 PM, C.Koy wrote: Java, C#, Python, Ruby... are all case-sensitive. This is not a feature to be (mis-)used so that one can have a function named myfunc() and MyFunc() in the same code base. Case-insensitive class/function/interface names is a confusion for everyone with non-PHP development experience. There's not a modern OO platform that defines an interface named 'IDispatch' and later allows it to be referenced as 'idispatch' or 'iDispatch'. And PHP is becoming more OO with every major release. Overall, full case-sensitivity seems to be a natural step in PHP's evolution. Let me add this: case-insensitivity is a burden for tool developers. For example, any ctags-based editor/IDE out there won't find the definition of myfunc() when you request Goto tag's definition if it's defined as MyFunc(). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
