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

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