On Wed, May 2, 2012 at 5:23 AM, C.Koy <can5...@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<can5...@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.
