Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130493
Content-Type: text/plain; charset=utf-8; format=flowed
Message-ID: <1774865754117.837705560.675399630@yahoo.de>
To: lamentxu@163.com
Cc: Ilia <ilia@ilia.ws>, internals@lists.php.net
Subject: Re: Re:Re: Re:Re: [PHP-DEV] [RFC] Remove \0 from default trim()
 character mask
Date: Mon, 30 Mar 2026 11:30:45 +0000
In-Reply-To: <c58d210.60b.19d3e22f5f5.Coremail.lamentxu@163.com>
References: <c58d210.60b.19d3e22f5f5.Coremail.lamentxu@163.com>
User-Agent: Vivaldi Mail/7.9.3970.45
Content-Transfer-Encoding: 7bit
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)

On Monday 30 March 2026 11:46:11 (+02:00), LamentXU wrote:

 > Thank you for ideas! AFAIK here are my thoughts on this
 > 
 > 
 > Now I realized the point that, those trim functions are not supposed to 
be used to remove whitespaces in strings, which solves my main concern that 
NUL is not a 'space' character. 
 > 
 > 
 > 
 > On top of that, we still have security concerns (and more) for this 
change, **and therefore I would like to withdraw this RFC.**
 > 
 > 
 > Moreover, the proposed new function 'trim_whitespace()' seems to be more 
reasonable for people to use to strip whitespaces instead of casually using 
the trim family, which would obviously be a better solution in this case.
 > 
 > 
 > Thank you for your attention and suggestions!

Thank you!

And yes, the security thing is the blocker on NUL, but if trim_space() idea 
clicked, and given your interest in topic and the bit precision you've 
shown, may I ask you if you have some interest in implementing it? Take 
your time for the answer, just sharing that I think your spotting of the 
"missing \f" shows attention to detail, and this is certainly both required 
and trim-able when there is need to delve into UTF-8 for the new idea (I 
have borrowed it from Golang as you wrote in both of your suggestions we 
should do more language comparison, which also was very insightful for me, 
so thank you for that, too!)

Apart from that, what are your thoughts about/for a constant preserving the 
original characters so in case the first change poses a problem for 
language users, they can find it and go on with it? -- That was a question 
raised shortly with the first RFC, in how far the change will introduce 
problems (albeit no one wants this), but because \f is that old it is hard 
to answer that question technically I think (even if we scan tons of 
code-bases for usages), so probably my thinking was that we should not 
leave users alone in case it is an issue for them and with a standard 
constant Tim or so can do some compiler string magic probably even. But 
that might be a bit my fantasy, we would first need to have a constant(?) 
before it could be discussed with him/other PHP compiler people. I'm open 
for other ideas/thoughts as well, the constant was a bit of an 
after-thought when writing, and it's good when you stay in the driver seat, 
I can only try to give some explanation when I see it or you ask and offer 
help with explorative testing. You own it, you make it out!

Thank you again!

-- hakre