Edit report at https://bugs.php.net/bug.php?id=62097&edit=1
ID: 62097
Updated by: cataphr...@php.net
Reported by: kazuo at o-ishi dot jp
Summary: New behavior of string == has a compatibility
problem
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 5.4.4RC1
-Assigned To: cataphract
+Assigned To: stas
Block user comment: N
Private report: N
New Comment:
I'm reassigning to stas, as which branches changes go to is primarily his
decision.
Previous Comments:
------------------------------------------------------------------------
[2012-05-28 10:29:56] kazuo at o-ishi dot jp
> The new rule is the same as the old rule, with the following
> limitation of numeric comparisons: If both strings look like integers
> (no decimal separator nor exponent) but they were both converted to
> doubles because of being too large in absolute value, if they both
> compare equal in a double comparison, and if they're both larger than
> 2^53-1 in absolute value, then compare them as a string.
Why this change is Right, in spite of breaking backward compatibility
from 5.4.3 to 5.4.4? What kind of tests are needed to the users to
migrate PHP 5.4.3 to PHP 5.4.4 safely?
I know this change was introduced to fix Bug #54547, but it's side
effects are not small.
I agree your first comment on #54547 :
>> Maybe this should be Won't Fix to keep it consistent with
>> 9223372036854775807 == 9223372036854775808 (with number literals).
------------------
> I agree that this is not a model of simplicity -- I'd have preferred a
> custom string comparison for number-like values -- but it's working as
> expected.
This need "Backward Incompatible Changes" section like
http://www.php.net/manual/en/migration54.incompatible.php ...
Please keep compatibility.
Even though this change will be done, I would like you to do it for PHP 5.5.
------------------------------------------------------------------------
[2012-05-28 09:07:31] cataphr...@php.net
The old rule is:
If the strings look like numbers (i.e they follow the notation for a decimal or
hexadecimal integer once any leading whitespace or leading zeros -- immediately
before the first non-zero digit -- are ignored), then they are compared as
numbers, except if the conversion result in infinite values with the same side,
in which case they are compared as strings. The number comparison is a double
comparison if any of the strings is converted to a double (due to a decimal
separator, exponent or the number being too large in absolute value) and it's
an integer comparison otherwise.
The new rule is the same as the old rule, with the following limitation of
numeric comparisons:
If both strings look like integers (no decimal separator nor exponent) but they
were both converted to doubles because of being too large in absolute value, if
they both compare equal in a double comparison, and if they're both larger than
2^53-1 in absolute value, then compare them as a string.
In light of this:
"1234567890123456789" == "12345678901.23456789E8" (32-bit)
1234567890123456789 > 2^31-1, so it cannot be represented as long => converted
to double => compared as double => compares equal => 1234567890123456789 >
2^53-1 => compare as string => FALSE
"9223372036854775808" == "09223372036854775808" (64-bit)
1234567890123456789 > 2^63-1, the same follows
"9223372036854775808" == " 9223372036854775808" (64-bit)
idem
For the rest of the 32-bit examples, 9007199254740992 is also larger than
2^53-1, so the the string comparison will be triggered.
I agree that this is not a model of simplicity -- I'd have preferred a custom
string comparison for number-like values -- but it's working as expected.
------------------------------------------------------------------------
[2012-05-27 18:11:38] kazuo at o-ishi dot jp
Hi,
This is one more case in 32-bit build:
"1234567890123456789" == "12345678901.23456789E8"
=> TRUE in 5.4.3
FALSE in latest
In addition, as I had already reported,
(64-bit environment)
"9223372036854775808" == "09223372036854775808"
=> TRUE in 5.4.3
FALSE in latest
"9223372036854775808" == " 9223372036854775808"
=> TRUE in 5.4.3
FALSE in latest
(32-bit environment)
"9007199254740992" == "9007199254740992."
=> TRUE in 5.4.3
FALSE in latest
"9007199254740992" == " 9007199254740992"
=> TRUE in 5.4.3
FALSE in latest
"9007199254740992" == "09007199254740992"
=> TRUE in 5.4.3
FALSE in latest
----------------------
I think that NEW RULE of == comparing is difficult
to understand and there are some incompatibility from OLD RULE.
At least, it is needed to be described explicitly.
(Of course, OLD RULE is already complex enough...)
OLD RULE:
When both strings look like numbers, they are converted to numbers
before == comparing.
Conversion rule from string to number is described in
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
If the string does not contain any of the characters '.', 'e', or
'E' and the numeric value fits into integer type limits (as
defined by PHP_INT_MAX), the string will be evaluated as an
integer. In all other cases it will be evaluated as a float.
And NEW RULE?
------------------------------------------------------------------------
[2012-05-26 11:52:09] cataphr...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
------------------------------------------------------------------------
[2012-05-24 09:10:51] cataphr...@php.net
Automatic comment on behalf of cataphract
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=acd711685a592c52be200e248154283c6c49c9f8
Log: Fixed bug #62097
------------------------------------------------------------------------
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=62097
--
Edit this bug report at https://bugs.php.net/bug.php?id=62097&edit=1
