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 AM LamentXU <[email protected]> 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: [email protected] T: @iliaa B: http://ilia.ws
