Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547
Comment by: riel at surriel dot com
Reported by: peter dot ritt at gmx dot net
Summary: wrong equality of string numbers
Status: Verified
Type: Bug
Package: Unknown/Other Function
Operating System: linux
PHP Version: 5.3.6
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
Conversion of numeric-looking strings to numbers does not have to be a problem, as long as the code
in the back end uses arbitrary-precision math. This is slower than comparing a type that fits in a
CPU register, but once you have already spent the time to do an automatic type conversion, that
really does not matter.
When it comes to an operator like ==, every digit matters. Having == return false when two items are
different violates the principle of least surprise.
Previous Comments:
------------------------------------------------------------------------
[2012-04-12 17:03:32] jacob at fakku dot net
@rasmus
I just wanted to point out the issue mentioned in that article and how I felt it
applied to this situation.
At least to me, it seems to me that it's a big deal when '9223372036854775807' ==
'9223372036854775808' returns true, even if it's an edge case. But you're right
about just using ===, which I will do if I ever run into this situation. After
doing a bit more research I can understand why it is the way it is and I was
probably too hasty to jump into this thread.
------------------------------------------------------------------------
[2012-04-12 16:53:54] rasmus@php.net
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump("61529519452809720693702583126814" ===
"61529519452809720000000000000000");'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
------------------------------------------------------------------------
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print "Allowed!\n";
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is "ximaz", which has
an all-numeric hex-encoded MD5 hash of "61529519452809720693702583126814". When
PHP does the comparison, it will print "Allowed!" for any password which matches
even the first half of the hash:
$ php -r 'var_dump("61529519452809720693702583126814" ==
"61529519452809720000000000000000");'
bool(true)
The solution, of course, is "never use type-coercing comparison operators" - but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
------------------------------------------------------------------------
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass in the original
case), then fall back on other comparison methods when they don't match? I admit I don't
have test cases but it seems that this would be backwards compatible in most cases (as you will
eventually compare numerically) and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as equal.
------------------------------------------------------------------------
[2012-04-12 15:20:45] jpauli@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1