Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130452
Precedence: list
MIME-Version: 1.0
References: <3f4f6959.eaf.19cf0276cd8.Coremail.lamentxu@163.com>
 <4bf704c.b746.19d20d429ac.Coremail.lamentxu@163.com> <CAAKU0umogV26u-Y9jc76XfU4cF4CN22Hs72bCYs1YQtYpac1qA@mail.gmail.com>
 <CADyq6s+5zM4RCT02_VDQG01RvxYpwYvJRK5BSppszPkMZ5Hd6A@mail.gmail.com>
In-Reply-To: <CADyq6s+5zM4RCT02_VDQG01RvxYpwYvJRK5BSppszPkMZ5Hd6A@mail.gmail.com>
Date: Wed, 25 Mar 2026 15:47:31 +0100
Message-ID: <CADO21-3nerbgg3y=uyAWcKGX0qPMCPEP9F3wTvzBjLzMVWZvEg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Remove \0 from default trim() character mask
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000379443064dda5bf6"
From: markus.podar@gmail.com (Markus Podar)

--000000000000379443064dda5bf6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Mar 25, 2026 at 11:04=E2=80=AFAM Marco Pivetta <ocramius@gmail.com>=
 wrote:

>
> On Tue, 24 Mar 2026 at 19:29, Levi Morrison <levi.morrison@datadoghq.com>
> wrote:
>
>> There hasn't been much discussion, so dear internals: are simply busy,
>> un-opinionated, or what?
>>
>
> I'd vote against this proposal: `\0` being considered one of the stripped
> characters is now a downstream assumption, and this ends up being a BC
> break with little to no advantages.
>
> From a semantic perspective, `\n`, `\t` and `\r` are also "control
> characters" in other contexts (not the C world).
>

Thanks for putting this into clear works: this is exactly my fear too.

Since the very first message of this thread arrived here, my thoughts were
along the lines this is outright dangerous to do: there is "decades" of
downstream assumption how this works and it's IMPOSSIBLE to properly vet
this, as this operates often on the (potentially untrusted) input level.

And, AFAICS, a perfectly valid workaround is possible by just providing as
custom 2nd arg.

IM(H)O this should never come to a vote, doing this shouldn't even be
considered.

sincerely,
- Markus

--000000000000379443064dda5bf6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 25, 2=
026 at 11:04=E2=80=AFAM Marco Pivetta &lt;<a href=3D"mailto:ocramius@gmail.=
com">ocramius@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, 24 Mar 2026 at 19:29, Levi Morris=
on &lt;<a href=3D"mailto:levi.morrison@datadoghq.com" target=3D"_blank">lev=
i.morrison@datadoghq.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
There hasn&#39;t been much discussion, so dear internals: are simply busy,<=
br>
un-opinionated, or what?<br></blockquote><div><br></div><div>I&#39;d vote a=
gainst this proposal: `\0` being considered one of the stripped characters =
is now a downstream assumption, and this ends up being a BC break with litt=
le to no advantages.</div><div><br></div><div>From a semantic perspective, =
`\n`, `\t` and `\r` are also &quot;control characters&quot; in other contex=
ts (not the C world).</div></div></div></blockquote><div><br></div><div>Tha=
nks for putting this into clear works: this is exactly my fear too.</div><d=
iv><br></div><div>Since the very first message of this thread arrived here,=
 my thoughts were along the lines this is outright dangerous to do: there i=
s &quot;decades&quot; of downstream assumption how this works and it&#39;s =
IMPOSSIBLE to properly vet this, as this operates often on the (potentially=
 untrusted) input level.</div><div><br></div><div>And, AFAICS, a perfectly =
valid workaround is possible by just providing as custom 2nd arg.</div><div=
><br></div><div>IM(H)O this should never come to a vote, doing this shouldn=
&#39;t even be considered.</div><div><br></div><div>sincerely,</div><div>- =
Markus</div></div></div>

--000000000000379443064dda5bf6--