Bug #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour
| From: | radamanf at gmail dot com | Date: | Thu, 14 Feb 2013 17:14:35 +0000 |
| Subject: | Bug #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-176630@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=39579&edit=1
ID: 39579
Comment by: radamanf at gmail dot com
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:
This is a epic FAIL in pure logic of comparing formats not having explicitly defining them, whole
beauty of PHP disappear! This is BROKEN LOGIC.
Connected BUGS
Bug #44990
Bug #39579
Different people are coming across this BUG and thinking the same as me, so please CHANGE your
documentation, it's WRONG! Who is this "GENIES" to make possible converting String to
Integer NOT INT TO STRING!
Guys, I'm very disappointed! :)
Previous Comments:
------------------------------------------------------------------------
[2013-02-14 17:14:35] radamanf at gmail dot com
This is a epic FAIL in pure logic of comparing formats not having explicitly defining them, whole
beauty of PHP disappear! This is BROKEN LOGIC.
Connected BUGS
Bug #44990
Bug #39579
Different people are coming across this BUG and thinking the same as me, so please CHANGE your
documentation, it's WRONG! Who is this "GENIES" to make possible converting String to
Integer NOT INT TO STRING!
Guys, I'm very disappointed! :)
------------------------------------------------------------------------
[2012-08-01 10:31:16] v dot picture at free dot fr
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.
------------------------------------------------------------------------
[2006-11-22 11:36:19] mgf@php.net
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] mgf@php.net
And, besides, this behaviour is documented at
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
------------------------------------------------------------------------
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