Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <jnr8vk$dih$1@dough.gmane.org>
References: <CA+Ky_uNZ_zmi8cwU0XLw+kQ_J=rJh_dRktoSb5pHX7A0hx2Fng@mail.gmail.com>
 <jnb8vp$jds$1@dough.gmane.org> <CA+Ky_uPUE_2GkfX3BSux01=EMemnYD3-H9xqoJiJEJWJWa9UkA@mail.gmail.com>
 <jnr8vk$dih$1@dough.gmane.org>
Date: Wed, 2 May 2012 12:03:13 -0700
Message-ID: <CA+Ky_uNSW8savMBUNOJ=oPKt6LrwM5-K68rOYJOiPTVSMAkmPg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf301d41c03472e404bf12594f
Subject: Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
From: ww.galen@gmail.com (Galen Wright-Watson)

--20cf301d41c03472e404bf12594f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 2, 2012 at 5:23 AM, C.Koy <can5koy@gmail.com> wrote:

> On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
>
>> On Thu, Apr 26, 2012 at 3:45 AM, C.Koy<can5koy@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?


>
>> 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.
>
>
Yup.

    $ LC_CTYPE=tr_TR php
    <?php
    setlocale(LC_CTYPE, 'en_US');
    class I {}
    $i = new I;
    ^D
    Fatal error: Class 'I' not found in - on line 4

    Call Stack:
        0.3740     630760   1. {main}() -:0

I should say that the Vulcan Logic Disassembler has been very helpful to me
in exploring this bug. Thank you, Derick Rethans and the rest of the VLD
team. If you haven't tried it, check it out.


> [...]
>
>
>
>> 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")
>
>
That's indeed what I meant; basically, the locales specified in the
LC_CTYPE &c. environment variables.

It shouldn't matter that the default locale isn't "en_US" or "C", as long
as PHP always uses the same locale for identifiers both during compilation
and at run-time. Of course, it also makes a certain amount sense to
explicitly decide that PHP will use a specific locale for identifiers. I
avoided suggesting that route to avoid any issues about what locales will
be universally available.


> 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.
>
>
That would set the locale to whatever the platform uses natively. Without
the call, the locale would be "POSIX"/"C", according to the POSIX doc (
http://pubs.opengroup.org/onlinepubs/009604499/functions/setlocale.html).
It doesn't seem terribly relevant to bug 18556, since all that matters
regarding the initial locale is that its lowercase conversion is different
from the locale that's used at run-time. If I had to guess why the locale
is set to the platform native, it's so that numeric, currency and date
formatting will be consistent with the rest of the system.

--20cf301d41c03472e404bf12594f--