Edit report at https://bugs.php.net/bug.php?id=39579&edit=1
ID: 39579
Updated by: nikic@php.net
Reported by: iain at workingsoftware dot com dot au
Summary: Comparing zero & string values in boolean comparison
has unexpected behaviour
Status: Not a bug
Type: Feature/Change Request
Package: Variables related
Operating System: FreeBSD 6.1
PHP Version: 5.2.0
Block user comment: N
Private report: N
New Comment:
> I wonder why this problem has not been solved so far.
It so happens that this problem *has* been solved, in PHP 8.0. Please see https://wiki.php.net/rfc/string_to_number_comparison
for more information.
Previous Comments:
------------------------------------------------------------------------
[2021-04-14 20:48:08] ehsan at chavoshi dot no--spam dot com
This behavior has the potential to cause many logical errors.At the same time, it is not easy to
change it, and changing it also causes logical errors in existing programs.
My strong suggestion is to throw a E_NOTICE when the result of the comparison would have been
different if the typecasting had not been done. (or anytime typecasting occurred when comparing two
values) .
showing a safe NOTICE attracts the programmer's attention and at the same time does not cause
any problems in running programs.
I wonder why this problem has not been solved so far.
------------------------------------------------------------------------
[2020-06-19 16:24:55] amfriedman at gmail dot com
This "feature" just burned an hour of my time as I wracked my brain trying figure out why
a continue; statement in my foreach loop was being triggered. I had an value of (int) 0 in one of
the array items, and it passed an if-test that compared it to a particular string. Super
frustrating.
I think PHP should generate a Notice to give the developer a head's up about this
"gotcha".
------------------------------------------------------------------------
[2014-05-28 13:53:44] rasmus@php.net
The transitive property of equality doesn't apply to a type-coercing equality check because the
types matter in each comparison. So you can't say that since
0 == '0' and 0 == 'a' then '0' must be equivalent to 'a'. In
the first two comparisons you are comparing integers to strings and in the last one you are
comparing two strings. These are completely different situations for a type-coercing equality
operator like ==
If you don't want to juggle types, simply use ===
------------------------------------------------------------------------
[2014-05-28 13:25:20] tom at r dot je
To expand on my point above:
0 == '0' //TRUE
Here, 0 and '0' are equivalent. However:
0 == 'a'; //TRUE
'0' == 'a'; //FALSE
Here, 0 and '0' are not equivalent which is very inconsistent.
If 0 is equivalent to '0' and 0 is equivalent to 'a' than it logically follows
that '0' is equivalent to 'a'; which is clearly not the case, and nor should it
be to fix this logical contradiction the only option is to make 0 and 'a' not equivalent.
As for the problems presented above about actually implementing a change, why not do what's
been done before and add an INI setting (settable via ini_set). Any scripts which do rely on this
broken functionality can just call ini_set for compatibility with the old operator.
------------------------------------------------------------------------
[2014-05-27 15:41:55] tom at r dot je
I have to agree with the above, this is illogical and confusing. What just caught me out was an
internal conversion from string to int which triggered the bug (and yes I definitely consider this a
bug.) Try this:
<?php
$arr = array('0' => 'Abc');
$keys = array_keys($arr);
if ($keys[0] == 'foo') {
echo 'String\'s equal';
}
?>
------------------------------------------------------------------------
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=39579
--
Edit this bug report at https://bugs.php.net/bug.php?id=39579&edit=1