Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85449
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.88 as permitted sender)
Message-ID: <BLU436-SMTP34001F28C093D64F89F882E20A0@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <006301d06637$ebbb4ee0$c331eca0$@php.net>
Date: Tue, 24 Mar 2015 15:17:41 +0100
CC: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAF+90c-CbGZ1d3DJSbzPmCbpjm6Pw3qPXQ=CG4XvbaM+528+jQ@mail.gmail.com> <006301d06637$ebbb4ee0$c331eca0$@php.net>
To: francois@php.net,
 Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
From: bobwei9@hotmail.com (Bob Weinand)

> Am 24.03.2015 um 14:39 schrieb Fran=C3=A7ois Laupretre =
<francois@php.net>:
>=20
>> De : Nikita Popov [mailto:nikita.ppv@gmail.com]
>>=20
>> The mbstring extension supports replacing PHP string functions with
>> multibyte variants through the mbstring.func_overload ini option.
>>=20
>> 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.
>>=20
>> If we do not wish to drop support for this option in PHP 7, I would =
at
>> least suggest to deprecate it.
>=20
> Probably fine, but how does your suggestion fit in the PHP 7 timeline =
? The BC break requires it is introduced in 7.0. And it is too late for =
this. As everyone seems to be against delaying the timeline, I hope we =
won't accept exceptions.
>=20
> Regards
>=20
> Fran=C3=A7ois

No, he isn't asking for delaying the timeline. He's asking if we can do =
this without RFC. Minimal self-contained changes don't need a RFC and =
can go as well into alpha/beta phase without issues.

Nikita, I assume with dropping you meant throwing a warning in case the =
option is detected and remove its functionality? Removing it completely =
in 7.0 may cause silent failures...
If yes, I'm fine with dropping that ini switch.

Thanks,
Bob=