Re: Re: [PHP-DEV] [RFC] Remove \0 from default trim() character mask

> Reasons for supporting > - semantically NUL is not whitespaces > - the majority of other popular languages don't trim NUL > Reasons for not supporting > - Java do trim NUL > - Security issues in existing code base > - Already has mb_trim() and the second parameter instead to prevent trimming NUL if people want > - Unnecessary changes in the life-cycle I think it would be useful if there were some examples of when you would want to be using trim but _not_ trim NULL bytes. The examples in the RFC currently show the expected change in behaviour; which is good - but you could also achieve the same effect by not running trim in the first place, as the only character in the examples that is expected to be removed before or after the change is the NULL byte (even in the example with a new line followed by null bytes, after the change then the string would be identical to before the trim). Given that most voters seem to be not strongly against, but also seeing no benefit in changing the status quo, some examples of how the change being used would be useful might help. ~ Robert On Wed, Mar 25, 2026 at 6:15 AM LamentXU <lamentxu@163.com> wrote: > > I think there are sound opinions in both side so I will still let the vote begin and see what > the majority thinks. To be short, > > Reasons for supporting > - semantically NUL is not whitespaces > - the majority of other popular languages don't trim NUL > Reasons for not supporting > - Java do trim NUL > - Security issues in existing code base > - Already has mb_trim() and the second parameter instead to prevent trimming NUL if people want > - Unnecessary changes in the life-cycle > > This is a quite minor change (and thats why people don't talk about this before, since > little people run into the case of trimming NUL). > > Well my opinion is, first I think trimming is indeed for white-spaces. I know Java do trim > NULs, but it doesn't explicitly do that, it removes every char with ascii <= 20 (and I think > most people are using strip() instead, which doesn't remove NUL), besides almost every other > standard or language don't trim NUL. So in the case of aligning with popular standards or > languages it make sense to avoid trimming NUL. > > Security and life-cycle concerns are good points. Un-trimming NUL may cause a sort of path > hacking as Ilia mentioned, while php trimming \0 is already well-known among some php devs who ran > into this case before. > > We has a second character to alter the trimmed char set, but I do think most people would > expect it not to be trimmed by default aligning with other languages. > > At 2026-03-25 03:15:25, "Ilia" <ilia@ilia.ws> wrote: > > That seems a bit dangerous, since non-stripped \0 can allow it to 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. > > Just my 2c. > > On Sun, Mar 15, 2026 at 2:23 AM 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 formatting (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 the BC impact before moving forward. >> >> Cheers, >> Weilin Du > > > > -- > Ilia Alshanetsky > Technologist, CTO, Entrepreneur > E: ilia@ilia.ws > T: @iliaa > B: http://ilia.ws