Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48203
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.219 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=UbdEsegdZO0LIcxN7tTgF3GxYevXFJ9+Cl3iWW+6Y3uB4gi3PuKDT2VSR/jd1MyOlK
         VWA4VjKwbeVITaYh4NKj4fBFY+LBSFm2hMWMZR54MCp6mNYCWYJmLpkbcB+wAzaEYzPg
         WvJY2A6p7fjkKbxjpiToKlYNkCHJu09W9/FAs=
MIME-Version: 1.0
Sender: ekneuss@gmail.com
In-Reply-To: <o2rab8cc41a1005040800sa8ac6494j8c31b1a1f42b7409@mail.gmail.com>
References: <r2se50d0a481004182058i1ca96f6ka9f7a4e545c98e5e@mail.gmail.com>
	 <o2rab8cc41a1005040800sa8ac6494j8c31b1a1f42b7409@mail.gmail.com>
Date: Tue, 4 May 2010 18:22:35 +0200
Message-ID: <s2ze666c3891005040922r956cea95z22150f32ccd6e862@mail.gmail.com>
To: Joel Perras <joel.perras@gmail.com>
Cc: Adam Harvey <aharvey@php.net>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Turkish/Azeri locale support
From: webmaster@colder.ch (Etienne Kneuss)

Hi,

A definite, -1 for #2, it's a _massive_ BC break with no justification
so far IMHO.

The optimization point is quite moot, tolower could be restricted to
compilation + dynamic accesses, which would remove most of them
already.

OTOH option #1 seems like the most sensible approach, breaking only in
very limited cases, so +1 from me.

Best,

On Tue, May 4, 2010 at 5:00 PM, Joel Perras <joel.perras@gmail.com> wrote:
> +1 for option #2.
>
> Jo=C3=ABl.
>
> On Sun, Apr 18, 2010 at 11:58 PM, Adam Harvey <aharvey@php.net> wrote:
>> As at least some of you would already be aware, there's a
>> long-standing issue with using PHP in a Turkish or Azeri locale,
>> namely that case-insensitive lookups within the Zend engine (method
>> names, for example) fail on lookups involving upper-case I characters,
>> since lower-case I in those languages is =C4=B1 instead of i (note the l=
ack
>> of a dot).
>>
>> The long term plan for this, per bug #35050 and any number of
>> duplicates, was to deal with it in PHP 6. Since PHP 6 isn't going to
>> happen in its original form, I think we're going to need to revisit
>> how we want to deal with this. There's a patch linked in the bug from
>> Tomas Kuliavas and Marcus that fixes the problem by simply redefining
>> zend_tolower() to a simple locale-insensitive ASCII tolower()
>> function, which does fix the Turkish and Azeri locales.
>>
>> The potential breakage from this is that single-byte locales will no
>> longer get case-insensitive lookups of non-ASCII characters: for
>> example, somebody using fr_FR.ISO-8859-1 as a locale could no longer
>> call a method =C3=89() as =C3=A9(). Since it doesn't break anything when=
 using
>> multi-byte locales (which have never had case-insensitive lookups
>> anyway since the Zend Engine uses the single-byte tolower()
>> internally), my inclination would be to apply the patch on trunk and
>> document it as a BC issue.
>>
>> I've uploaded an updated version of Tomas's patch that applies cleanly
>> to trunk to http://www.adamharvey.name/patches/35050/zend_operators.c.di=
ff
>> and a phpt file to test the fix to
>> http://www.adamharvey.name/patches/35050/bug35050.phpt. It's likely
>> that the test would require massaging before being committed to work
>> on Windows, but since I don't have a Windows development box readily
>> available and don't know a thing about how Windows implements locale
>> support, this would require help from someone familiar with the
>> platform.
>>
>> So: thoughts; concerns; alternate approaches? It would be nice to have
>> this sorted for PHP.next.
>>
>> Thanks,
>>
>> Adam
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> I do know everything, just not all at once. It's a virtual memory problem=
.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Etienne Kneuss
http://www.colder.ch