Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130437
Precedence: list
MIME-Version: 1.0
References: <3f4f6959.eaf.19cf0276cd8.Coremail.lamentxu@163.com>
In-Reply-To: <3f4f6959.eaf.19cf0276cd8.Coremail.lamentxu@163.com>
Date: Tue, 24 Mar 2026 15:31:13 -0400
Message-ID: <CALkpNnT3njeR955rQwG2oegM8UKQMmiGuEfL3UWH=6owput_Lw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Remove \0 from default trim() character mask
To: LamentXU <lamentxu@163.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006cdc25064dca32a6"
From: ilia@ilia.ws (Ilia)

--0000000000006cdc25064dca32a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

That seems a bit dangerous, since non-stripped \0 can potentially lead to
issues because when concatinated with other strings, which is quite common
for string operations can result in un-predictability and possibly even
security issues.

You make a good point about other languages, the concern is while there
that is the expecation and different solutions exist for
sanitizing/handling \0 they are well known and understood, in PHP the
assumption is that \0 is removed and the change of this assumption breaks a
lot of things. Trim functions already allow 2nd parameter with character
list, so it is already possible to exclude \0 from being trimmed.

Just my 2c.

On Sun, Mar 15, 2026 at 2:23=E2=80=AFAM LamentXU <lamentxu@163.com> wrote:

> Dear all,
>
> I am sending this to introduce my new RFC:
> https://wiki.php.net/RFC/dont_trim_NUL
>
> Quick summary:
>
> Currently, PHP's trim functions strip the NUL byte (\0) by default,
> treating it alongside spaces, tabs, and newlines. This creates a highly
> surprising edge case.
>
> Because \0 is semantically a control character or a vital part of a
> binary payload rather than a typographical whitespace character, casually
> using trim() to clean up trailing newlines can silently corrupt binary
> streams or cryptographic hashes by stripping legitimate NUL bytes.
> Whitespace characters are intended for typographical spacing and formatti=
ng
> (e.g., spaces, newlines, tabs).
>
> Also, almost every mainstream programming languages except PHP doesn't
> trim NUL characters (python, go, rust, js, even 'is_space' function in
> glibc...) It sounds reasonable to expect the same here.
> This RFC proposes removing \0 (ASCII 0) from the default character mask.
> I recognize this introduces a backward compatibility break, and therefore=
 I
> would love to hear your thoughts, feedback, and any concerns regarding th=
e
> BC impact before moving forward.
>
> Cheers,
> Weilin Du
>


--=20
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

--0000000000006cdc25064dca32a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That seems a bit dangerous, since non-stripped \0 can pote=
ntially lead to issues because when concatinated with other strings, which =
is quite common for string operations can result in un-predictability and p=
ossibly even security issues.=C2=A0<div><br></div><div>You make a good poin=
t about other languages, the concern is while there that is the expecation =
and different solutions exist for sanitizing/handling \0 they are well know=
n and understood, in PHP the assumption is that \0 is removed and the chang=
e of this assumption breaks a lot of things. Trim functions already allow 2=
nd parameter with character list, so it is already possible to exclude \0 f=
rom being trimmed.</div><div><br></div><div>Just my 2c.</div></div><br><div=
 class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Sun, Mar 15, 2026 at 2:23=E2=80=AFAM LamentXU &lt;<a href=3D"mai=
lto:lamentxu@163.com">lamentxu@163.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div style=3D"line-height:1.7;color:r=
gb(0,0,0);font-size:14px;font-family:Arial"><div style=3D"margin:0px">Dear =
all,</div><div style=3D"margin:0px"><br></div><div style=3D"margin:0px">I a=
m sending this to introduce my new RFC:=C2=A0<a href=3D"https://wiki.php.ne=
t/RFC/dont_trim_NUL" target=3D"_blank">https://wiki.php.net/RFC/dont_trim_N=
UL</a></div><div style=3D"margin:0px"><br></div><div style=3D"margin:0px">Q=
uick summary:</div><div style=3D"margin:0px"><p>Currently, PHP&#39;s trim f=
unctions strip the NUL byte (<code>\0</code>) by default, treating it along=
side spaces, tabs, and newlines. This creates a highly surprising edge case=
.</p><p>Because <code>\0</code> is semantically a control character or a vi=
tal part of a binary payload rather than a typographical whitespace charact=
er, casually using <code>trim()</code> to clean up trailing newlines can si=
lently corrupt binary streams or cryptographic hashes by stripping legitima=
te NUL bytes. Whitespace characters are intended for typographical spacing =
and formatting (e.g., spaces, newlines, tabs).</p><p>Also, almost every mai=
nstream programming languages except PHP doesn&#39;t trim NUL characters (p=
ython, go, rust, js, even &#39;is_space&#39; function in glibc...) It sound=
s reasonable to expect the same here.</p>This RFC proposes removing <code>\=
0</code> (ASCII 0) from the default character mask.
I recognize this introduces a backward compatibility break, and therefore I=
 would love to hear your thoughts, feedback, and any concerns regarding the=
 BC impact before moving forward.

<br></div><div style=3D"margin:0px"><br></div><div style=3D"margin:0px">Che=
ers,=C2=A0</div><div style=3D"margin:0px">Weilin Du</div></div></blockquote=
></div><div><br clear=3D"all"></div><div><br></div><span class=3D"gmail_sig=
nature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><di=
v dir=3D"ltr">Ilia Alshanetsky<div>Technologist, CTO, Entrepreneur</div><di=
v>E: <a href=3D"mailto:ilia@ilia.ws" target=3D"_blank">ilia@ilia.ws</a></di=
v><div>T: @iliaa=C2=A0</div><div>B: <a href=3D"http://ilia.ws" target=3D"_b=
lank">http://ilia.ws</a></div></div></div>

--0000000000006cdc25064dca32a6--