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.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
