Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <50.00.26446.A7E72155@pb1.pair.com>
References: <CAF+90c-CbGZ1d3DJSbzPmCbpjm6Pw3qPXQ=CG4XvbaM+528+jQ@mail.gmail.com>
	<66c0cca2453de53bed0328af2732c7bd@mail.gmail.com>
	<50.00.26446.A7E72155@pb1.pair.com>
Date: Wed, 25 Mar 2015 13:44:17 +0000
Message-ID: <CAGAGxbbpDoanY3Y=jLuij+gfQOOqjncsruKR8k4jEc6UKr9eTQ@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e014942e680d81205121d18c0
Subject: Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
From: cw@daverandom.com (Chris Wright)

--089e014942e680d81205121d18c0
Content-Type: text/plain; charset=UTF-8

On 25 March 2015 at 09:22, Tony Marston <TonyMarston@hotmail.com> wrote:

> "Zeev Suraski"  wrote in message news:66c0cca2453de53bed0328af2732c7
> bd@mail.gmail.com...
>
>
>>  -----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
>>
>
> I sell my software in several Asian countries, and they regularly use this
> ini option. Unless you can point to a fully-supported alternative I am
> against dropping this option.
>
>
With the best will in the world, the fully supported alternative is to
explicitly use the mbstring functions and handle encodings correctly. For
the most part, one could trivially attain identical functionality without
falling foul of the deprecation by means of a simple search/replace. The
purpose of a change like this would be to remove a wtf factor and encourage
people to write more explicit code.

Note also that what is being proposed here is merely a deprecation - it
won't actually break anything, giving people plenty of time to gracefully
migrate their codebases.

That said, in the interests of not causing people using this functionality
issues with logs full of errors and/or error-related performance issues, I
would support having this deprecation set up in such a way that an error is
only issued at most once per request - there's no need to issue a
deprecation warning at every function call.


> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e014942e680d81205121d18c0--