Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60422 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97625 invoked from network); 2 May 2012 12:23:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 May 2012 12:23:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-php-dev@m.gmane.org; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=can5koy@gmail.com; sender-id=unknown Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.3 as permitted sender) X-PHP-List-Original-Sender: php-php-dev@m.gmane.org X-Host-Fingerprint: 80.91.229.3 plane.gmane.org Received: from [80.91.229.3] ([80.91.229.3:44229] helo=plane.gmane.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/1A-38165-94721AF4 for ; Wed, 02 May 2012 08:23:38 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SPYaj-0003ir-8s for internals@lists.php.net; Wed, 02 May 2012 14:23:33 +0200 Received: from 94.54.3.12 ([94.54.3.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 May 2012 14:23:33 +0200 Received: from can5koy by 94.54.3.12 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 May 2012 14:23:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: internals@lists.php.net Date: Wed, 02 May 2012 15:23:08 +0300 Lines: 51 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gmane-NNTP-Posting-Host: 94.54.3.12 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Subject: Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP) From: can5koy@gmail.com ("C.Koy") On 5/1/2012 9:11 PM, Galen Wright-Watson wrote: > On Thu, Apr 26, 2012 at 3:45 AM, C.Koy 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. > > 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,