On 08/14/2011 02:37 PM, Rasmus Lerdorf wrote:
On 08/14/2011 02:03 PM, Stas Malyshev wrote:
Hi!
On 8/14/11 11:40 AM, Rasmus Lerdorf wrote:
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For people
And why should anybody care? 99% of people using PHP never used a libc
function and can hardly tell libc from gcc. If we can extend this
function with useful functionality, nobody cares about what libc does.
For example, I could imagine people writing code along these lines:
$len = strlen($user_data) - strlen($suffix);
if(!strncmp($user_data, $string, $len)) {
// do something
}
Warning doesn't fix the bug - and unless you're in 0.0001% of the
population that actually reads the logs daily and checks every message
there it would be little to help you. We should have more useful
functions, not more warnings. Warning won't make this code to work.
I agree, however this change would potentially change the return value
of the function. Before it would warn and not match. Even if you never
saw the warning, at least length -1 would not give you a match. Now if
the user data happens to end with the right character we now have a
string match which is not at all what the code was written to do.
Put more succinctly. Subtle BC breaks like this worry me. Any strncmp()
call with a computed length where that length may in some cases go
negative will now potentially return a match where it wouldn't before.
This would be very hard to track down. And the reason for introducing
this subtle BC break is so that you can rewrite:
if (substr("prefix_num", -3) == "num") {
echo "they have same suffix\n";
}
into:
if (strncmp("prefix_num", "num", -3) === 0) {
echo "they have same suffix\n";
}
That doesn't seem like a big win to me.