On 08/14/2011 11:26 AM, Stas Malyshev wrote:
> Hi!
>
>>> Maybe, but I would classify *that* as a bug as it makes no sense at all.
>
> Thinking more about it, something like:
>
> if(strncasecmp($filename, ".php", -4) === 0) {
> /* got php file! */
> }
>
> seems to me just fine and better than doing the same with substr. I
> would definitely be against the warning in this case.
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For people
familiar with the underlying functionality having a negative length
parameter do something would be confusing and in some cases could mask bugs.
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
}
That is, check to see if the part of a $user_data without a given suffix
matches $string. That should obviously also have a check to make sure
that $user_data is at least as long as $suffix, but if they forget this
check then they get a nice warning telling them that "Length must be
greater than or equal to 0." If we change this to now make negative
lengths work, code like this will do extremely unexpected things.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
