Hi everyone:
plz vote for this : "strn(case)cmp supporting a negative length as
its third paramter"
RFC: https://wiki.php.net/rfc/strncmpnegativelen#vote
if you have any objection, plz write back.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
This would make perfect sense with constant strings and constant
length, when using variables this may lead to some magic bugs, which
would be normally reported as E_WARNING. Not sure if it's a good idea
:(
Jan Dolecek
juzna.cz@gmail.com
Hi everyone:
plz vote for this : "strn(case)cmp supporting a negative length as
its third paramter"RFC: https://wiki.php.net/rfc/strncmpnegativelen#vote
if you have any objection, plz write back.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi:
I am not good at english, so I could not explain the idea very clearly
but I really think it was a good idea,,
could someone plz make a decision that make this patch applied to svn trunk?
thanks
2011/8/2 Jan Dolecek juzna.cz@gmail.com:
This would make perfect sense with constant strings and constant
length, when using variables this may lead to some magic bugs, which
would be normally reported as E_WARNING. Not sure if it's a good idea
:(Jan Dolecek
juzna.cz@gmail.comHi everyone:
plz vote for this : "strn(case)cmp supporting a negative length as
its third paramter"RFC: https://wiki.php.net/rfc/strncmpnegativelen#vote
if you have any objection, plz write back.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/--
--
Laruence Xinchen Hui
http://www.laruence.com/
HI:
and I don't think this was diffcult to accepted
it was a little improve, and make a litte change, even no bc break...
thanks
2011/8/6 Laruence laruence@php.net:
Hi:
I am not good at english, so I could not explain the idea very clearly
but I really think it was a good idea,,could someone plz make a decision that make this patch applied to svn trunk?
thanks
2011/8/2 Jan Dolecek juzna.cz@gmail.com:
This would make perfect sense with constant strings and constant
length, when using variables this may lead to some magic bugs, which
would be normally reported as E_WARNING. Not sure if it's a good idea
:(Jan Dolecek
juzna.cz@gmail.comHi everyone:
plz vote for this : "strn(case)cmp supporting a negative length as
its third paramter"RFC: https://wiki.php.net/rfc/strncmpnegativelen#vote
if you have any objection, plz write back.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/--
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.
the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salathe
it wins 2/3 vote, so I think this supposed to mean that accept, right?
thanks
2011/8/6 Laruence laruence@php.net:
HI:
and I don't think this was diffcult to accepted
it was a little improve, and make a litte change, even no bc break...thanks
2011/8/6 Laruence laruence@php.net:
Hi:
I am not good at english, so I could not explain the idea very clearly
but I really think it was a good idea,,could someone plz make a decision that make this patch applied to svn trunk?
thanks
2011/8/2 Jan Dolecek juzna.cz@gmail.com:
This would make perfect sense with constant strings and constant
length, when using variables this may lead to some magic bugs, which
would be normally reported as E_WARNING. Not sure if it's a good idea
:(Jan Dolecek
juzna.cz@gmail.comHi everyone:
plz vote for this : "strn(case)cmp supporting a negative length as
its third paramter"RFC: https://wiki.php.net/rfc/strncmpnegativelen#vote
if you have any objection, plz write back.
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/--
--
Laruence Xinchen Hui
http://www.laruence.com/--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is: Support : 6 felipe pajoye pierrick gwynne tyrael laruence Decline : 3 iliaa rasmus salathe it wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?
Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>
Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salatheit wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.
imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_num
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salatheit wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_num
Maybe, but I would classify that as a bug as it makes no sense at all.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_numMaybe, but I would classify that as a bug as it makes no sense at all.
I don't mind that, and imho laruence would be happy to change the
patch, after we fix this "bug".
But thats a separate issue, and we should also keep in mind the BC
break for that.
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi:
this just to say that stncasecmp has the same behavior of either
negative or postive length argument.
why you insist to this point? as strncmp("aaaa", "bbb", 1000000)
works with no warning, why negative length need trigger warnings?
thanks
2011/8/14 Derick Rethans derick@php.net:
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salatheit wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_numMaybe, but I would classify that as a bug as it makes no sense at all.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi:
I think what I was done is try to describe a image, that we can make
follow codes more simple:
if (strncmp(substr("num_suffix", 0, -5), "suffix", 5) == 0) {
echo "they have the same suffix";
}
yes, there is must something not good in my patch, but I think I
can tweak it as you wish.
the only thing I want you to accept is : " should this behavior is
more make sense for some occassion?"
thanks
2011/8/14 Laruence laruence@php.net:
Hi:
this just to say that stncasecmp has the same behavior of either
negative or postive length argument.why you insist to this point? as strncmp("aaaa", "bbb", 1000000)
works with no warning, why negative length need trigger warnings?thanks
2011/8/14 Derick Rethans derick@php.net:
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salatheit wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_numMaybe, but I would classify that as a bug as it makes no sense at all.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi all internalers:
Since there comes some new objections, I think I should open the
RFC voteing again.
to Derick, if I extended voting phase for two weeks , can we
consider this voteing valid?
I think this proposal is not explained clearly before, so I am
going to explain it agian,
and I am not good at english, so if I make you confused, sorry in advance.
-------
this RFC comes from a Featurn request: https://bugs.php.net/bug.php?id=36944
when I saw the request, I totally agree with the reporter, and I
think this feature can make sense for simplify following situation:
<?php
if (strncmp(substr("num_suffix", 0, -5), "suffix", 5) == 0) {
echo "they have the same suffix";
}
and you may wondering does negative length make sense?
yes, because substr supports it already:
<?php
echo substr("test", 0, -1);
Now this RFC is calling for vote again, plz read the RFC, and
vote for it: https://wiki.php.net/rfc/strncmpnegativelen
if you have any question about this, plz write back.
thanks.
2011/8/14 Laruence laruence@php.net:
Hi:
I think what I was done is try to describe a image, that we can make
follow codes more simple:if (strncmp(substr("num_suffix", 0, -5), "suffix", 5) == 0) {
echo "they have the same suffix";
}yes, there is must something not good in my patch, but I think I
can tweak it as you wish.the only thing I want you to accept is : " should this behavior is
more make sense for some occassion?"thanks
2011/8/14 Laruence laruence@php.net:
Hi:
this just to say that stncasecmp has the same behavior of either
negative or postive length argument.why you insist to this point? as strncmp("aaaa", "bbb", 1000000)
works with no warning, why negative length need trigger warnings?thanks
2011/8/14 Derick Rethans derick@php.net:
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salatheit wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_numMaybe, but I would classify that as a bug as it makes no sense at all.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
Laruence Xinchen Hui
http://www.laruence.com/--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi:
sorry, the example is wrong , it should be :
<?php
if (strncmp(substr("num_suffix", -5, 5), "suffix", 5) == 0) {
echo "they have the same suffix";
}
?>
thanks
2011/8/14 Laruence laruence@php.net:
Hi all internalers:
Since there comes some new objections, I think I should open the
RFC voteing again.to Derick, if I extended voting phase for two weeks , can we
consider this voteing valid?I think this proposal is not explained clearly before, so I am
going to explain it agian,and I am not good at english, so if I make you confused, sorry in advance.
-------
this RFC comes from a Featurn request: https://bugs.php.net/bug.php?id=36944
when I saw the request, I totally agree with the reporter, and I
think this feature can make sense for simplify following situation:<?php
if (strncmp(substr("num_suffix", 0, -5), "suffix", 5) == 0) {
echo "they have the same suffix";
}and you may wondering does negative length make sense?
yes, because substr supports it already:
<?php
echo substr("test", 0, -1);Now this RFC is calling for vote again, plz read the RFC, and
vote for it: https://wiki.php.net/rfc/strncmpnegativelenif you have any question about this, plz write back.
thanks.
2011/8/14 Laruence laruence@php.net:
Hi:
I think what I was done is try to describe a image, that we can make
follow codes more simple:if (strncmp(substr("num_suffix", 0, -5), "suffix", 5) == 0) {
echo "they have the same suffix";
}yes, there is must something not good in my patch, but I think I
can tweak it as you wish.the only thing I want you to accept is : " should this behavior is
more make sense for some occassion?"thanks
2011/8/14 Laruence laruence@php.net:
Hi:
this just to say that stncasecmp has the same behavior of either
negative or postive length argument.why you insist to this point? as strncmp("aaaa", "bbb", 1000000)
works with no warning, why negative length need trigger warnings?thanks
2011/8/14 Derick Rethans derick@php.net:
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
.the Voting result is:
Support : 6 felipe pajoye pierrick gwynne tyrael laruence
Decline : 3 iliaa rasmus salatheit wins 2/3 vote, so I think this supposed to mean that accept, right?
I voted against too. Also, you started the vote with not even a week
between RFC announcement and call for voting, so I guess that makes this
invalid?Just looked over the RFC, and this whole example is weird:
<?php
var_dump(strncmp("prefix_num", "num", -10));
?>Why does it even find the substring as you can't do "-10" from the end?
If the number is too high, it should give you a warning.imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_numMaybe, but I would classify that as a bug as it makes no sense at all.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
Laruence Xinchen Hui
http://www.laruence.com/--
Laruence Xinchen Hui
http://www.laruence.com/--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi!
imo the patch is consistent with how substr works:
tyrael@thor:~$ php -d display_errors=1 -d error_reporting=-1 -r 'echo
substr("prefix_num", -100);'
prefix_numMaybe, but I would classify that as a bug as it makes no sense at all.
It makes some sense, if you take the meaning of argument as "at most 100
characters". I'm not sure how useful it'd be backwards, but forward
something like "at most 100 chars" is very useful and warning, on the
contrary, in such situation would be useless and annoying. Why not make
backwards case symmetrical?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
Hi!
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.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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.
-Rasmus
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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
Hi:
compare to use substr, strncmp supporting negative lenght can
save a temp variable.
thanks
2011/8/15 Rasmus Lerdorf rasmus@php.net:
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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
--
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi,
Doesn't substr_compare()
accomplish the same thing since 5.1.0?
The only thing I couldn't figure out is how to make it case
insensitive without specifying an explicit value to $length
Best,
Tjerk
Hi:
compare to use substr, strncmp supporting negative lenght can
save a temp variable.thanks
2011/8/15 Rasmus Lerdorf rasmus@php.net:
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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
--
--
Laruence Xinchen Hui
http://www.laruence.com/--
--
Tjerk
Hi Tjerk:
yes, substr_compare can do it, and it also supports negative
length argument too.
but I am proposal to improve strn(case)cmp, so they are not conflict . :)
thanks
2011/8/15 Tjerk Anne Meesters datibbaw@php.net:
Hi,
Doesn't
substr_compare()
accomplish the same thing since 5.1.0?The only thing I couldn't figure out is how to make it case
insensitive without specifying an explicit value to $lengthBest,
TjerkHi:
compare to use substr, strncmp supporting negative lenght can
save a temp variable.thanks
2011/8/15 Rasmus Lerdorf rasmus@php.net:
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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
--
--
Laruence Xinchen Hui
http://www.laruence.com/--
--
Tjerk
--
Laruence Xinchen Hui
http://www.laruence.com/
Laruence wrote:
yes, substr_compare can do it, and it also supports negative
length argument too.
I am with Rasmus ... while the BC problem he is pointing out is probably very
rare, those are the worse ones to fix when they pop up intermittently, and
usually when 10 year old code has been working fine and suddenly starts doing it?
All of the original base str... functions currently follow the libc manual ( I
think ) and that is how they work. My first thought when the thread started was
that this needed a different name - which is exactly why substr_compare exists?
Although nothing is appearing in my archive, I'm sure that this discussion has
already happened long ago when this was added to PHP5? Perhaps it should be
linked in the SeeAlso from strncmp and the rest?
but I am proposal to improve strn(case)cmp, so they are not conflict .:)
One persons improvement can become someone elses BC nightmare?
I seem to recall a discussion about tidying up many of the string functions,
probably part of unicode compatibility, and in that vane, would it be possible
to create a 'namespace' version of string functions which could be a little more
consistent, and also offer the chance to switch to full unicode comparison if
required? sb:: -> mb:: transparently working the same way? needle and haystack
order comes to mind as well?
Is there any reason there is not an mb_substr_compare ?
Yes character based rather than byte. Seems to me that this is the way to go
rather than changing the other functions? Actually substr_compare will tidy up a
bit of a mess in my own code where I need to switch case on and off I'd just not
remembered it existed ....
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
probably part of unicode compatibility, and in that vane, would it be possible
to create a 'namespace' version of string functions which could be a little more
consistent, and also offer the chance to switch to full unicode comparison if
required? sb:: -> mb:: transparently working the same way? needle and haystack
order comes to mind as well?
It would be possible. If somebody actually does that :) People talk
about that for years, but nobody actually sat and did that.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Lester:
I totally agree with you about bc break things,
but actully I don't think this proposal will bring a big bc break,
it's a new approach , but not a big change,
I am meaning that the old codes can work fine because rarely codes
depends on a negative length.
do you agree?
thanks
2011/8/15 Lester Caine lester@lsces.co.uk:
Laruence wrote:
yes, substr_compare can do it, and it also supports negative
length argument too.I am with Rasmus ... while the BC problem he is pointing out is probably
very rare, those are the worse ones to fix when they pop up intermittently,
and usually when 10 year old code has been working fine and suddenly starts
doing it?All of the original base str... functions currently follow the libc manual (
I think ) and that is how they work. My first thought when the thread
started was that this needed a different name - which is exactly why
substr_compare exists? Although nothing is appearing in my archive, I'm sure
that this discussion has already happened long ago when this was added to
PHP5? Perhaps it should be linked in the SeeAlso from strncmp and the rest?but I am proposal to improve strn(case)cmp, so they are not conflict
.:)One persons improvement can become someone elses BC nightmare?
I seem to recall a discussion about tidying up many of the string functions,
probably part of unicode compatibility, and in that vane, would it be
possible to create a 'namespace' version of string functions which could be
a little more consistent, and also offer the chance to switch to full
unicode comparison if required? sb:: -> mb:: transparently working the same
way? needle and haystack order comes to mind as well?Is there any reason there is not an mb_substr_compare ?
Yes character based rather than byte. Seems to me that this is the way to go
rather than changing the other functions? Actually substr_compare will tidy
up a bit of a mess in my own code where I need to switch case on and off I'd
just not remembered it existed ....--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php--
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi Lester:
I totally agree with you about bc break things,but actully I don't think this proposal will bring a big bc break,
it's a new approach , but not a big change,I am meaning that the old codes can work fine because rarely codes
depends on a negative length.do you agree?
I agree that this is not a "big" BC break. However, my argument is that
small BC breaks like this are actually much worse than "big" BC breaks.
A big and obvious BC break is usually easy to deal with. An accumulation
of small subtle BC breaks that rarely hit you and then only on certain
input strings, those are the ones that kill you.
-Rasmus
Hi Rasmus:
could we well docuemnt this(changelog) to avoding such bad thing happen?
and sure, I agree and know what you are worried, also I am very
respect you .
so here is the thing, if I can't get your support, I think I
should darw back the proposal.
thanks
2011/8/15 Rasmus Lerdorf rasmus@lerdorf.com:
Hi Lester:
I totally agree with you about bc break things,but actully I don't think this proposal will bring a big bc break,
it's a new approach , but not a big change,I am meaning that the old codes can work fine because rarely codes
depends on a negative length.do you agree?
I agree that this is not a "big" BC break. However, my argument is that
small BC breaks like this are actually much worse than "big" BC breaks.
A big and obvious BC break is usually easy to deal with. An accumulation
of small subtle BC breaks that rarely hit you and then only on certain
input strings, those are the ones that kill you.-Rasmus
--
Laruence Xinchen Hui
http://www.laruence.com/
Perhaps it should be linked in the SeeAlso from strncmp and the rest?
I added substr_compare to the See Also sections of strcmp, strcasecmp,
strncmp and strncasecmp.
Apart from that: Now that we know that a function for doing such
comparisons exists, a change to strncmp doesn't make much sense
anymore. Only useless BC break.
Am 14.08.2011 23:52, schrieb Rasmus Lerdorf:
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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.
Or just
if (strncmp(strrev('prefix_num'), 'mun', 3) === 0) {
// do something
}
-Rasmus
Regards,
Sebastian
Hi:
I think we are not talking about how to accomplish a function, we
are talking about how to do it better
and, in fact, I think strrev is need more cpu time and alloc space,
although they are very tiny :)
thanks
2011/8/15 Sebastian Krebs sebastian.krebs.berlin@googlemail.com:
Am 14.08.2011 23:52, schrieb Rasmus Lerdorf:
Hi!
My main issue with changing strncmp/strncasecmp is that these are
currently exact mappings of the underlying libc functions. For peopleAnd 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.
Or just
if (strncmp(strrev('prefix_num'), 'mun', 3) === 0) {
// do something
}-Rasmus
Regards,
Sebastian--
--
Laruence Xinchen Hui
http://www.laruence.com/
Laruence wrote:
I think we are not talking about how to accomplish a function, we
are talking about how to do it betterand, in fact, I think strrev is need more cpu time and alloc space,
although they are very tiny :)
I very much doubt it's ever going to be a bottleneck (and I think the
same about strncmp vs. substr; no real need to avoid a temp variable). I
could see this patch being useful, but personally, I think the substr
solution is a better one, since it doesn't risk breaking BC, as Rasmus
noted.
--
Ryan McCue
<http://ryanmccue.info/
Hi!
Dear all:
I am going to close strn(case)cmp supporting negative length vote,
since it has been calling for vote near two weeks, and no new feedback
I think we need some more time to discuss it. Give it a week, then let's
see.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227