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: Wont fix
+Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 5.4.4RC1
-Assigned To:
+Assigned To: cataphract
Block user comment: N
Private report: N
New Comment:
Ah, very well. The code is indeed wrong for 32-bit machines. I hadn't
considered that.
Previous Comments:
------------------------------------------------------------------------
[2012-05-22 09:48:36] kazuo at o-ishi dot jp
Sorry, typo in PHP version.
PHP 5.3.3 -> PHP 5.4.3
PHP 5.3.4RC1 -> PHP 5.4.4RC1
------------------------------------------------------------------------
[2012-05-22 06:22:18] kazuo at o-ishi dot jp
I'm not talking about new feature or functionality.
I'm talking about incompatible behavior which has been introduced by
https://github.com/php/php-src/commit/47db8a9aa19f6e17a1018becf9978315c79a1cb0
for bug #54547.
Other case.
Build 32bit PHP. [PHP_INT_MAX = 2147483647]
Using PHP 5.3.3 (before change):
"02147483647" == "2147483647"
=> TRUE (OK)
"02147483648" == "2147483648"
=> TRUE (OK: compared as float, and float can handle this precision)
But using PHP 5.3.4RC1:
"02147483647" == "2147483647"
=> TRUE (OK)
"02147483648" == "2147483648"
=> FALSE (BAD!)
------------------------------------------------------------------------
[2012-05-21 23:09:36] cataphr...@php.net
On a closer look, what's mentioned in the e-mail is not exactly the same thing
because I was comparing a "always string" comparison and a string comparison as
a fallback to a float comparison.
In any case, the problem you're mentioning could only be solved by a custom
comparison function, a solution that was not favored in this discussion.
------------------------------------------------------------------------
[2012-05-21 23:05:11] cataphr...@php.net
Thanks for your report.
I raised this issue in internals:
http://www.mail-archive.com/internals@lists.php.net/msg58598.html
(see near the end)
and this was deemed a "very narrow use case".
So I'm marking this Wont Fix now, but feel free to take this issue to the
internals mailing list.
------------------------------------------------------------------------
[2012-05-21 17:09:25] kazuo at o-ishi dot jp
Description:
------------
The behavior of string comparison using == operator is changed in
https://github.com/php/php-src/commit/47db8a9aa19f6e17a1018becf9978315c79a1cb0
to fix bug #54547.
This change has a compatibility problem.
Before this change (PHP 5.4.3),
"01234" == "1234"
=> TRUE (OK)
"09223372036854775808" == "9223372036854775808"
=> TRUE (compared as float, but result is acceptable)
After change,
"01234" == "1234"
=> TRUE (OK)
"09223372036854775808" == "9223372036854775808"
=> FALSE (compared as string)
This behavior is not reasonable in that case.
New rule is not clear.
I think this change should be reverted, before release of 5.4.4.
Test script:
---------------
echo (("01234" == "1234") ? "true" : "false"), "\n";
echo (("09223372036854775808" == "9223372036854775808") ? "true" : "false"),
"\n";
Expected result:
----------------
true
true
Actual result:
--------------
true
false
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=62097&edit=1
