Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60259
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <jn0go8$sam$1@dough.gmane.org>
References: <jmrdbg$bh4$1@dough.gmane.org> <CA+Ky_uM+m3pvDguD5+ihnJiz_FTmQd2LwdkdY_WjWDaJnyPBzw@mail.gmail.com>
 <jn0go8$sam$1@dough.gmane.org>
Date: Sun, 22 Apr 2012 13:32:28 -0700
Message-ID: <CA+Ky_uOUc66zGCoMiGigtWeNF=MpF_upTyGYhaCv-P08Y-toNg@mail.gmail.com>
To: "C.Koy" <can5koy@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=90e6ba6e82e4fc34ac04be4a6db7
Subject: Re: [PHP-DEV] Complete case-sensitivity in PHP
From: ww.galen@gmail.com (Galen Wright-Watson)

--90e6ba6e82e4fc34ac04be4a6db7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2012/4/22 C.Koy <can5koy@gmail.com>

> 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 bac=
k
>> before returning. Then, any appropriate function (e.g.
>> zend_resolve_class_name, zend_lookup_class_ex, class_exists,  class_alia=
s)
>> 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 "=C4=B1" 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.
>
> The fix would need to be applied to at least four functions, so adding a
new function would be more maintainable. Also, there are locales that don't
begin with "tr_" or have "TR" in the locale name, so the condition would
need to be more complex.

Converting "I" or "=C4=B1" separately from lowercase conversion is less
performant than either option I describe, as it requires an extra loop,
which is why I didn't bother suggesting it. I suspect switching the locale
is most performant, as it doesn't require additional tests, though I
haven't examined the cost of setting the locale.


> 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 spa=
n
> and dozens of comments/complaints on the bug's entry, it's hard to say th=
is
> 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? If anything, that a fix "does
not take a genius" is an argument in its favor, if it also solves the
problem.

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.


> 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.
>
> It is, but it's also a major BC break, hence perhaps better suited for
PHP6. Case-sensitivity is also a much bigger issue than this bug. A custom
conversion function, on the other hand, produces the minimum impact of any
option I've read. As such, it's hopefully a solution for this bug that
everyone can agree on.


>> 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.
>
> 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.

--90e6ba6e82e4fc34ac04be4a6db7--