Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 74.125.82.41 as permitted sender)
References: <CAF+90c-CbGZ1d3DJSbzPmCbpjm6Pw3qPXQ=CG4XvbaM+528+jQ@mail.gmail.com>
In-Reply-To: <CAF+90c-CbGZ1d3DJSbzPmCbpjm6Pw3qPXQ=CG4XvbaM+528+jQ@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQINGwJxyuYhIX37R6FSHjGdA0ViXZyyVwgw
Date: Tue, 24 Mar 2015 08:25:15 -0700
Message-ID: <66c0cca2453de53bed0328af2732c7bd@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Tuesday, March 24, 2015 4:45 AM
> To: PHP internals
> Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
> 7
>
> Hi internals!
>
> The mbstring extension supports replacing PHP string functions with
> multibyte variants through the mbstring.func_overload ini option.
>
> This ini setting is a real PITA for code compatibility, as it makes it
> impossible
> to rely on the output of even the most basic PHP functions, like strlen().
> Security-critical code in libraries and frameworks typically handles this
> issue
> by conditionally using either strlen() or 8bit mb_strlen(). Apart from
> that, the
> issue is generally ignored.
>
> If we do not wish to drop support for this option in PHP 7, I would at
> least
> suggest to deprecate it.
>
> Thoughts?

I think we need to understand how it's actually being used before discussing
its deprecation.  IIRC it's extremely widely used in Japan, but could be
wrong.
I'd want to hear from our Japanese contributors what their thoughts are.

Zeev