Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102612
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVrJo8BH=gMf07qq9MsgT6ziqWJO6JPgxVgVuStr+-5cpw@mail.gmail.com>
References: <CAF+90c_+GZNrV1SC9q=Y3C=L3LMnoXX7J3zK6=kS9-sMXHZZow@mail.gmail.com>
 <CAESVnVrJo8BH=gMf07qq9MsgT6ziqWJO6JPgxVgVuStr+-5cpw@mail.gmail.com>
Date: Thu, 5 Jul 2018 20:13:26 +0200
Message-ID: <CAF+90c8=RQ=15WadiDDVnx2HoWDeTGLWuHJ+G1BWO1mG6OJuzA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fe8aad05704480a4"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000fe8aad05704480a4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <pollita@php.net> wrote:

> On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > https://wiki.php.net/rfc/deprecations_php_7_3
> >
> > Undocumented mbstring function aliases
> >
> Yeah, if they're just dumb aliases, then it's a slight gain to narrow
> the symbol table by removing duplicates.  A modest composer package
> (nay, include file) would be sufficient to provide a bridge for
> existing projects which use the removed aliases once they're gone.
> This deprecation isn't *needed*, but it's also fairly low impact. =F0=9F=
=A4=B7
>
> > String search functions with integer needle
> >
> Agree with stas, the wtf quotient on this one is high.  Mitigating
> this is the availability of strict types, but even still I think
> deprecating the behavior altogether is a wise move.  Callers can
> easily insert a call to chr() (or IntlChar::chr() ) to maintain the
> old behavior in a version agnostic way. =F0=9F=98=95
>
> > fgetss() function and string.strip_tags filter
> >
> "...these functions seem to be of very little utility..." [citation neede=
d]
> Anecdotally I struggle to imagine the use-case, but my imagination
> isn't what it once was.  There's not a trivial workaround for someone
> who's dealing with a large/streaming data source from which they want
> to strip tags.  Deprecating this should come at a higher standard of:
> proving that it is used, providing a userspace replacement, or both.
> =F0=9F=98=A4
>

As an insight into how much this functionality is used from a somewhat
unexpected direction: While implementing the deprecation, I found out that
the string.strip_tags filter does not have a single test and has been
segfaulting on construction since PHP 7.0 if no allowed tags are specified
(and performed OOB reads if they were specified). These issues have been
fixed in
https://github.com/php/php-src/commit/791f07e4f06a943bd7892bdc539a7313fb3d6=
d1e
.

Nikita

--000000000000fe8aad05704480a4--