Edit report at https://bugs.php.net/bug.php?id=39579&edit=1
ID: 39579
Comment by: v dot picture at free dot fr
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: Bug
Package: Variables related
Operating System: FreeBSD 6.1
PHP Version: 5.2.0
Block user comment: N
Private report: N
New Comment:
Hi, I'm wondering why this comparison should be evaluated in a numeric context
and not a string context, after all
there is no loss with string casting whereas there is a huge risk of doing
mistakes with numeric casting:
(string) 0 => "0"
(string) 42.5 => "42.5"
(int) "test" => 0
But ok, let's say it's a normal behavior.
"If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to
a number"
Then why would PHP decide to do that in a string context ? I mean, when I
compare two strings I don't expect PHP to
convert everything to numbers !
"10" == "1e1" => true
Sorry folks, this really seems like a string context to me.
Previous Comments:
------------------------------------------------------------------------
[2006-11-22 11:36:19] [email protected]
It's not a problem -- it's a feature, and it's documented at the address I've
just quoted, which describes evaluation of a string in any numeric context.
------------------------------------------------------------------------
[2006-11-22 11:14:47] iain at workingsoftware dot com dot au
it's not the behaviour of how a string is cast to an integer that i'm talking
about, but if i have a comparison:
if($value == Class::CONSTANT)
and the class constant is a string, it's not immediately apparent that if
$value == 0 then this will evaluate to true. maybe warning is too strong, but a
notice might be good in the event that a non-strict == operation returns true
because one of the operands is 0 and the other operand is a value that
evaluates to 0 when cast as an int.
anyway, i guess if php has been around for this long without anyone mentioning
it yet ... i mean, this is the first time i've come across the problem. if a
notice had been emitted it would have been a time saver.
------------------------------------------------------------------------
[2006-11-22 11:06:57] [email protected]
And, besides, this behaviour is documented at
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
------------------------------------------------------------------------
[2006-11-22 09:39:26] [email protected]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
That's how PHP works and it won't change.
------------------------------------------------------------------------
[2006-11-22 08:35:22] iain at workingsoftware dot com dot au
well it seems to me that at least a warning should be given when comparing an
integer 0 to a non-integer value that evaluates to 0 when cast as an int unless
an explicit type cast is used without using strict equals.
i can see why this behaviour is not a bug, because (int)'SOME STRING' == 0, but
it's also has the potential to cause unexpected results/bugs unless you use
strict equals everywhere.
in this case, i fixed the problem by using === instead of ==, but it took a bit
of time to track down the error because there was no warning or anything. i
think that it would be better to require someone to do:
if($value == (int)'SOME STRING')
OR
if($value === 'SOME STRING')
in order to avoid a warning being emmited if $value == 0.
------------------------------------------------------------------------
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
