Bug #54547 [Com]: wrong equality of string numbers

From: Date: Thu, 12 Apr 2012 15:55:26 +0000
Subject: Bug #54547 [Com]: wrong equality of string numbers
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-169490@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=54547&edit=1

 ID:                 54547
 Comment by:         yless42 at hotmail 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:

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.


Previous Comments:
------------------------------------------------------------------------
[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

------------------------------------------------------------------------
[2012-04-12 14:17:32] nikic@php.net

@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where everything is a
string) and MySQL (where also everything is returned as a string). So in PHP you will often deal
with numbers in strings, thus they should be handled as such.

------------------------------------------------------------------------
[2012-04-12 14:02:02] Jeff at bobmail dot info

That didn't address my comment. Why wouldn't the internal implementation check to see if
the strings are the same? When doing a comparison and the internal data type is a string,
wouldn't that be faster and most correct?

In all honesty I would prefer PHP's "loosely typed" system mimic JavaScript's in
that any type can be put anywhere but the object still keeps its type information for situations
just like this.

------------------------------------------------------------------------
[2012-04-12 13:59:32] nikic@php.net

@Jeff: You have to understand in PHP 1, 1.0 and "1.0" all are equivalent (in most
situations). That's by design.

E.g. GET and POST variables are always strings, even if you put numbers into them (as per the HTTP
standard). PHP obviously wants those GET/POST variables to still be useable just like they were
numbers, that's why "1" and 1 can be used interchangeably throughout PHP.

In that context - in my eyes - this comparison also makes sense. Consider a very similar comparison:

    var_dump('0.1' == '0.10000000');

What would you expect to be the output - if you remember that in PHP numeric strings and actual
numbers are interchangeable? Clearly it has to behave exactly as if you had written:

    var_dump(0.1 == 0.10000000); // => bool(true)

In most cases this type of comparison is what you want and it usually works exactly as expected.

What you see here in this issue is one of the edge cases (how often do you use large numbers in
PHP?) where it does not work well.

I hope you understand that it is not viable to remove a handy feature from PHP, just because it
fails under certain edge case conditions.

If you want to use a strict string comparison, just use ===.

------------------------------------------------------------------------
[2012-04-12 13:58:53] pajoye@php.net

@Jeff at bobmail dot info

that's what === is for (real comparisons without casting).

------------------------------------------------------------------------


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


Thread (44 messages)

« previous php.bugs (#169490) next »