When you call trim() without a second argument, it strips a default set of characters: spaces, tabs, newlines and a few others, including the NUL byte \0. This RFC from Weilin Du would remove \0 from that default list for trim(), ltrim() and rtrim().
Why change it
The author argues that a NUL byte isn't whitespace but a control character. C uses it to terminate strings, and binary formats often use it for padding. If you trim a binary payload to drop a stray newline, you can lose real data along with it, and the author says this happened in their own code.
The RFC also notes that most other languages don't treat NUL as whitespace, listing Python, JavaScript, Ruby, Go and glibc.
Show me
$packet = "STATUS:OK\n\0\0"; // Current behavior: returns "STATUS:OK" var_dump(trim($packet)); // Proposed behavior: returns "STATUS:OK\n\0\0" var_dump(trim($packet));
Today both the newline and the NUL bytes get stripped. Under the RFC, trim() stops at the NUL bytes, so nothing is removed from that end.
Ordinary text trims the same as before:
echo trim(" Hello World \n\t "); // Outputs: "Hello World"
What it means for existing code
This would break code that relies on trim() removing NUL bytes. The RFC expects little impact on most web apps, though it could affect older scripts that clean up C-style strings from database drivers or FFI.
If you want the old behavior, you can pass the old character list yourself: " \f\n\r\t\v\0". The RFC suggests tools like PHPStan, Psalm or Rector could add it for you automatically.
Where it stands
The author withdrew the RFC before it reached a vote. It had targeted PHP 8.6.