3

I was just debugging a script and found that an if-statement wasn't working the way I expected it to.

var_dump("6064365413078728979" == "6064365413078728452");
die();

The code above will result in the following:

bool(true)

With the === operator it works as expected. Anyone got any ideas why?

I'm using PHP Version 5.3.13 with a wamp installation on a x64 windows machine.

Improve this question
6
  • on my php version 5.3.10 your code returns false. Commented Jan 10, 2013 at 13:37
  • That returns false. Not sure how you're getting true. Commented Jan 10, 2013 at 13:37
  • it's because a non-empty string is equivalent to true.. you're like comparing TRUE == TRUE.. === operator however is sensitive with the data type Commented Jan 10, 2013 at 13:39
  • While we research, please could you say us what is the value of PHP_INT_MAX for your server? Commented Jan 10, 2013 at 13:53
  • int(2147483647) so you are right about that. Thx everybody for your help. Should i change the 'right' answer to yours for future purposes? Commented Jan 10, 2013 at 14:13

2 Answers 2

Reset to default
7

PHP has loose type comparison behavior, so your numerical strings are getting converted to integer types before == non strict comparison, and the conversion result is overflowing.

That is the principal reason to use === when it's possible.

Take a look at this page for further details on type juggling.

Improve this answer
Sign up to request clarification or add additional context in comments.

12 Comments

So they get converted, eventhough they are both strings?
Yes, maybe my aknowledges is a few limited, but PHP is the only language i've learnt that does this. But the answer is yes: PHP will see what's inside your strings befeore deciding how to cast them.
@Gordon, in your case this is equal to 1 == 0, but in this case integers are overflowing. Let me a second to add some information about PHP integer limits (which depends on the machine, so there will be some interesting info in that)
@Áxel Its not just about int. Even floats have a limit based upon architecture. So your answer still stands true. In his case this limit might be exceding.
Yes, it can exceed based on architecture. Although i do not know exact max right now but he could be on a 32 bit architecture and that limits out below that point probably
|
3 
<?php
$a=6064365413078728979;
$b=6064365413078728452;
echo $a."<br>".$b;
//var_dump( $a==$b );
die();
?>

When you run that, then on your machine that might be exceeding limit for a number and that is a numeric comparison taking place. Try the script above and see value for $a will probably be different than the value you gave.

That is why when both are compared numerically they are equal. Hence use === as suggested by others

Edit: Explanation based upon @Axel's Advice.

PHP Manual explains

The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format).

And this website is offering and explanation on the Overflow phenomenon and a small php code to test your system's integer and float range. Getting to know the limit on your servers will most probably explain it best why the offerflow occured

Improve this answer

3 Comments

@Lubje See both are same :)
@HankyPanky, may you complete you answer with some link to PHPdocs about type juggling, stirng conversion and PHP int and float limits to make a perfect wiki question of this? After doing so I'll delete my answer. If you feel happy to do that I'll be very glad.
Hmmm... Not exaclty. Our discovery was that in the end there was no overflow, but the strings were converted to float and the integer part was devaluated until both numbers were equal in its representation... Do you think you can improve ti?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.