Bug #44999 [Com]: 0 equals any string

2013-02-14 Thread radamanf at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=44999&edit=1

 ID: 44999
 Comment by: radamanf at gmail dot com
 Reported by:ethan dot nelson at ltd dot org
 Summary:0 equals any string
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   windows 2003
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

I can see that it's no any logical explanation to keep this BUG unfixed! 
Status: Not a bug -> why??? It's not funny, so many years past.

I do love to use PHP and like that no needed to define variable types, but this 
is generic FAIL.

Come one guys, someone need to fix this, please.

My PHP version
PHP 5.3.10-1ubuntu3.5 with Suhosin-Patch (cli) (built: Jan 18 2013 23:45:59)


Previous Comments:

[2012-08-24 08:16:07] bugs dot php dot net at simoneast dot net

This is quite ridiculous.  Can this 'feature' of PHP *please* be reconsidered?


[2008-05-14 22:25:51] ethan dot nelson at ltd dot org

I don't recall PHP ever behaving that way.

So how do you alter a switch statement to use the identical operator instead of 
equivalency?

It seems somewhat odd that any text character would be equvalent to integer 0.  
As I remember the chart it was something like:
0 == '0' true
0 == '' true
0 == null true
0 == false true
0 == 'text' false

Basically if we are going to treat any string as equivalent to 0, the switch 
statement becomes useless when iterating through arrays unless you first strip 
key names of integer 0.


[2008-05-14 22:20:01] cel...@php.net

see Bug #44990 for explanation


[2008-05-14 21:51:49] ethan dot nelson at ltd dot org

Description:

Right now, 0 compared to any string will prove true.

Reproduce code:
---


Expected result:

False

Actual result:
--
True






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=44999&edit=1


Bug #44990 [Com]: array('word')==array(0) -- true

2013-02-14 Thread radamanf at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=44990&edit=1

 ID: 44990
 Comment by: radamanf at gmail dot com
 Reported by:design at apostolstudio dot com
 Summary:array('word')==array(0) -- true
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows XP
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

Comparison === needed ONLY if, during type conversion, we got same values, so 
String compare to Integer should be compared using Integer converted to string 
and check if they are equal. 

So if String is '' and Int is 0
or '1' == 1
'2' == 2
.. etc. only in this cases === is necessary to tell VARIABLE TYPE difference.

It's so obvious, why I'm explaining all this to you ?! You should know this 
better than me! Please fix this BUG


Previous Comments:

[2008-05-14 02:58:01] design at apostolstudio dot com

Thanks for explanations.


[2008-05-14 02:39:53] cel...@php.net

use ===

'word' is converted to an integer for the comparison, and thus 0 == 0.

try this code:

if(array('word')===array(0)) echo "ERROR";


[2008-05-14 02:27:10] design at apostolstudio dot com

Description:

array('word')==array(0) -- return true

Reproduce code:
---
if(array('word')==array(0)) echo "ERROR";

Actual result:
--
ERROR






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=44990&edit=1


Bug #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour

2013-02-14 Thread radamanf at gmail dot com
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] m...@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] m...@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


Bug #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour

2013-02-14 Thread radamanf at gmail dot com
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:

I've seen a topic in the web: 
http://josephscott.org/archives/2012/03/why-php-strings-equal-zero/ related to 
this bug, and I can see that sometimes string need to be compared with integer 
as integer BUT this is a huge pool of potential bugs across all the worldwide! 
:) Can you imagine how many people usign PHP without realizing this BUG ! :)_) 
I'm sure this is a loved BUG by most hackers out there !


Previous Comments:

[2013-02-14 17:24:51] ni...@php.net

@radamanf: Stop shouting. Shouting does not help.

I agree that this behavior ('foo' == 0) is counter-productive. I think most 
people would agree on that. But even if everyone agrees that it's the wrong 
behavior, changing it isn't so easy. Changing this behavior will probably break 
existing software.

If you really want to change this, then there is only one way: Make the change 
and then test a shitload of code against it. See how many tests will fail in 
major PHP projects and how easy things are to fix.

If you can provide sufficient data that this change (which goes rather deep 
into the core semantics of the language) won't affect existing projects 
heavily, then I see no problem with doing it.

--------
[2013-02-14 17:14:35] radamanf at gmail dot com

Related To: Bug #39579

--------
[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] m...@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.




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


Req #39579 [Com]: Comparing zero & string values in boolean comparison has unexpected behaviour

2013-02-15 Thread radamanf at gmail dot com
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:   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:

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.


Previous Comments:

[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.

--------
[2013-02-14 17:26:40] radamanf at gmail dot com

I've seen a topic in the web: 
http://josephscott.org/archives/2012/03/why-php-strings-equal-zero/ related to 
this bug, and I can see that sometimes string need to be compared with integer 
as integer BUT this is a huge pool of potential bugs across all the worldwide! 
:) Can you imagine how many people usign PHP without realizing this BUG ! :)_) 
I'm sure this is a loved BUG by most hackers out there !


[2013-02-14 17:24:51] ni...@php.net

@radamanf: Stop shouting. Shouting does not help.

I agree that this behavior ('foo' == 0) is counter-productive. I think most 
people would agree on that. But even if everyone agrees that it's the wrong 
behavior, changing it isn't so easy. Changing this behavior will probably break 
existing software.

If you really want to change this, then there is only one way: Make the change 
and then test a shitload of code against it. See how many tests will fail in 
major PHP projects and how easy things are to fix.

If you can provide sufficient data t