Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAL+t6cH+hKKgWWwF2z8bqX9Sbh1090GPewEMLKc_1ateH3+adA@mail.gmail.com>
References: <CAGa2bXbjh7EyzRf_uahHp0rfs21efqReHZKQchvB8CGjNc_Qaw@mail.gmail.com>
 <CAGa2bXbGdC-6hcdEdQmzUn8xVKLa5Ro9NyGyFkhuMueoXuoing@mail.gmail.com>
 <CADajX4DxvtZ3+fX5f6ndHOGmGs+ZAgSPFkRHVOqUwO9y5y1ZZg@mail.gmail.com>
 <CAGa2bXZH1rgh7XzQd-Tswdod4gRAxgj9-fc-hV=49JrEK8fpdw@mail.gmail.com> <CAL+t6cH+hKKgWWwF2z8bqX9Sbh1090GPewEMLKc_1ateH3+adA@mail.gmail.com>
Date: Tue, 17 Dec 2013 07:38:07 +0900
Message-ID: <CAGa2bXazAQ9edoq-z9URLZwgAP77yH+MZrsgLpg9+Xe4Ce7QTA@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: Adam Harvey <aharvey@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2d662577a2d04edae7a76
Subject: Re: [PHP-DEV] Re: Making addslashes() multibyte aware
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2d662577a2d04edae7a76
Content-Type: text/plain; charset=UTF-8

On Tue, Dec 17, 2013 at 7:13 AM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:

> On Mon, Dec 16, 2013 at 4:41 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> On Tue, Dec 17, 2013 at 5:54 AM, Adam Harvey <aharvey@php.net> wrote:
>>
>> > On 16 December 2013 12:44, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>  >  > I'll fix php_addslashes(). Therefore, any functions that use it
>> > internally
>> > > are affected. e.g. var_export(), etc. Users are not affected as long
>> as
>> > > they are using correct locale.
>> > >
>> > > Should I fix this from 5.3?
>> >
>> > This feels like it has the potential to be a really nasty implicit BC
>> > break. I don't think we'd want to change default behaviour on any
>> > stable branch, honestly.
>>
>>
>> I cannot object this argument.
>> There may be unexpected side effects.
>> However, users will not be affected as long as they are using correct
>> locale if locale system is not broken...
>>
>>
> But honestly, how many users will set their locale to SJIS/BIG5 when
> dealing with multibyte charsets like those? I typically never touch locales
> when dealing with code that handles multibyte charsets (and that's becoming
> more and more often these days), because it rarely makes sense. It makes a
> lot more sense to me to deal with those issues on the intl/mb_* level and
> as for serialization I hardly think that serialize() with addslashes is a
> problem PHP needs to fix. More likely the correct and better fix is for
> those developers to be more charset-conscious while making decisions about
> how to handle serialized data after transport.
>

There are many. SJIS, BIG5 and similar char encoding is used widely in East
Asia. For instance, Windows uses SJIS as default char encoding for Japanese
edition.

I bet you never touch locale since you don't have to. I suppose those who
have never touch locale will not be affected by this change.

The issue here is unreliable locale system for certain locales... Locale is
system dependent and we cannot do much for it. However, code uses locale is
in PHP already. e.g. escapeshellcmd/escapeshellarg/fgetcsv or like.

That's the reason why I decided to fix this with locale even if use of
locale is not optimum..

Alternative solution is to use mbstring.
It may be 5.6 only, but I don't mind much with this solution. In fact, I
prefer this ;)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c2d662577a2d04edae7a76--