Req #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour
| From: | mirroredfate at gmail dot com | Date: | Tue, 22 Oct 2013 18:42:19 +0000 |
| Subject: | Req #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-182388@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: mirroredfate 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: 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:
> It's not a problem -- it's a feature, and it's documented at the address
> I've just quoted
And I could document a webserver sometimes crashing when you click a button and call it a
"feature", but that doesn't make it so.
This is clearly counter-intuitive behavior and should be beaten to death with an iron rod after
being water-boarded. It is terrible. If you are defending this, you should probably take a long,
hard look at your life and your principles.
Making zero equal any string is just wrong. I completely goes against how PHP operates in every
other instance, and no doubt causes developers no end of distress and frustration. It's a
feature like how getting beaten up in a dark alley is a feature of that alley.
This needs to be fixed, people.
Previous Comments:
------------------------------------------------------------------------
[2013-07-03 00:36:56] iain at workingsoftware dot com dot au
Hey xtalviper, the reason it does this is because in the case of:
if($string)
then the string is cast to a boolean. If you do:
if($int == $string)
then the string is cast to an int.
You can see this more clearly by doing this:
<?php
$boolstring = (boolean)"string";
$intstring = (int)"string";
var_dump($boolstring);
var_dump($intstring);
------------------------------------------------------------------------
[2013-07-02 21:31:57] xtalviper at yahoo dot com
Here's the basic problem of logic that doesn't follow for me:
If I do
if(0) {
//...is false, this will never run
}
and I do
if("string") {
//...is true, will always run
}
Then how the hell can true == false
------------------------------------------------------------------------
[2013-02-15 10:08:27] radamanf at gmail dot com
Hi Nick, Thanks for your answers on both related bugs.
I apologize for my expressions.
But I'm still thinking this bug should be fixed one day, maybe on later day when a few
backwards compatible bugs will be found, so it makes more sense to fix it as a bunch. I hear that
PHP 5.3 was breaking release and some old code was not working since, it was the right time to fix
this bug.
The general logic should be: Convert less complicated variable type into more complicated type, so
convert Int up to String not bringing String down to Int. This need to be universal and according to
KISS logic. If geeks need to use strings for octal or hexadecimal then they know what they are doing
and need to cast such string as Int! To bring string down to Int.
v dot picture at free dot fr ->
"
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.
"
Someone need to write a great exploit to hack into eCommerce shops and produce unseen damage across
the Globe :) then this will not be funny at all.
I wish this patch could happen one day! Temporarily it could be at least a Warning, Iain suggested
to give a notice, but I believe this bug got a great hidden potential.
------------------------------------------------------------------------
[2013-02-14 22:52:25] iain at workingsoftware dot com dot au
Sorry I meant to submit this as "Feature/Change Request" but submitted the form
without a password and it changed back to "bug".
------------------------------------------------------------------------
[2013-02-14 22:50:15] iain at workingsoftware dot com dot au
Hi, I agree this shouldn't be changed. It's pretty fundamental to how PHP works
and since reporting this bug 6
years ago I've learned a lot more about PHP :)
I still think my suggestion of emitting a Notice whenever a string is converted
to 0 as a result of being
evaluated in a numeric context isn't too outlandish though.
*Changing* the way that strings are evaluated would break a buttload of code and
isn't really productive.
Emitting a Notice would help people unfamiliar with the implicit typecasting
behaviour save some time and
avoid bugs when developing. For those that like to write "clean code" with no
Notices there is a very simple
way of suppressing it (ie. use === or (int)).
Also, emitting a notice wouldn't actually break any code, although it might
cause a number of scripts out in
the wild to become more verbose in their logging - is that not an acceptable
risk?
The notice could even say something like:
Notice: String evaluated to 0 (zero) when used in numeric context on line
WHATEVER. Use === or (int) to
prevent this notice.
This would enable people to quickly understand the behaviour (which is kind of
unintuitive but fair enough
when you look at PHPs type system - just a foible of the language everyone
should learn) and encourage people
to learn the importance of === earlier on.
------------------------------------------------------------------------
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