Bug #62097 [Com]: New behavior of string == has a compatibility problem
Edit report at https://bugs.php.net/bug.php?id=62097&edit=1 ID: 62097 Comment by: steve at home dot com Reported by:kazuo at o-ishi dot jp Summary:New behavior of string == has a compatibility problem Status: Wont fix Type: Bug Package:Scripting Engine problem Operating System: Gentoo Linux PHP Version:5.4.4RC1 Assigned To:stas Block user comment: N Private report: N New Comment: kazuo at o-ishi dot jp: Just don't expect the PHP type system to make any sense, it's easier than trying to understand it at this point. Obviously the developer you are talking to does not understand this issue. If you want to have reliable behavior, PHP is not for you (unless you stick to a single version and work out the oddities). Previous Comments: [2012-05-31 06:23:30] s...@php.net I believe I did explain the reason and I believe this is reason enough. If you disagree, please feel free to raise it on internals list and if enough of the community supports you it will be reversed. So far I did not hear any more complaints about it. I think it is clear that there is a disagreement between us about how to handle this, and more discussion is not going to bring any improvement. I am closing this bug, if you feel more discussion is required please raise it on the list. [2012-05-31 02:36:51] kazuo at o-ishi dot jp I have shown test cases that work on released version 5.4.3 but not work on developing version. Now, YOU need explain real merit of this backward incompatible change. md5() is not enough reason, because it should always be compared by === instead of ==. Generally, at the case when new behavior (memcmp for large value) is acceptable, we can and we should just use ===. > If you have such code > sample and can explain what data it accepts, what it does and why it relies > on > string comparisons cutting numbers, please do so. Your database example is > missing data, so I can not see what is going on there and why you think it > works > differently in 5.4.3 and 5.4.4. (I'm sorry but I cannot understand what you say in this two sentence. Could you explain detail?) In JPY (Japan Yen), we normally use it in integer (e.g. 100 yen). But sometimes it take fraction (e.g. foreign exchange 1 USD = 78.80 JPY). So database column type with fraction is reasonable. And set to / get from the column in integer form is also reasonable. Again, I just report incompatibility from PHP 5.4.3 to PHP 5.4.4RC. This is wrong way if you want to fix security problem, because incompatible change makes the users difficult to migrate to new version. [2012-05-31 00:46:41] s...@php.net I do not see "heavy" impact - so far I did not see any code sample that did something that makes sense in 5.4.3 but not on 5.4.4. If you have such code sample and can explain what data it accepts, what it does and why it relies on string comparisons cutting numbers, please do so. Your database example is missing data, so I can not see what is going on there and why you think it works differently in 5.4.3 and 5.4.4. [2012-05-30 08:57:43] kazuo at o-ishi dot jp In summary, this is my opinion: Recent changes on string == have problems on compatibility. Impact of the behavior change of == operator is heavy. This change should be excluded from PHP 5.4.x series. I'm sure that current (old) behavior also have problems, but compatibility is better. If it will be changed, it should be a natural extension of current behavior; number-like string is compared as number. (e.g. canonicalize string as number way before memcmp.) Of course, such behavior should be described explicitly in PHP Manual. [2012-05-30 07:18:45] kazuo at o-ishi dot jp Please think that it is money (or member ID). But why? 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
Bug #62097 [Com]: New behavior of string == has a compatibility problem
Edit report at https://bugs.php.net/bug.php?id=62097&edit=1
ID: 62097
Comment by: kazuo at o-ishi dot jp
Reported by:kazuo at o-ishi dot jp
Summary:New behavior of string == has a compatibility
problem
Status: Wont fix
Type: Bug
Package:Scripting Engine problem
Operating System: Gentoo Linux
PHP Version:5.4.4RC1
Block user comment: N
Private report: N
New Comment:
Sorry, typo in PHP version.
PHP 5.3.3-> PHP 5.4.3
PHP 5.3.4RC1 -> PHP 5.4.4RC1
Previous Comments:
[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
Bug #62097 [Com]: New behavior of string == has a compatibility problem
Edit report at https://bugs.php.net/bug.php?id=62097&edit=1
ID: 62097
Comment by: kazuo at o-ishi dot jp
Reported by:kazuo at o-ishi dot jp
Summary:New behavior of string == has a compatibility
problem
Status: Wont fix
Type: Bug
Package:Scripting Engine problem
Operating System: Gentoo Linux
PHP Version:5.4.4RC1
Block user comment: N
Private report: N
New Comment:
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!)
Previous Comments:
[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
