Home » Php » php – Type casting and Comparison with Loose Operator "=="

php – Type casting and Comparison with Loose Operator "=="

Posted by: admin July 12, 2020 Leave a comment


I have a problem baffling me terribly. I noticed this before but didn’t give it any heed until today.
I was trying to write my own check for integer strings. I know of is_numeric() but it does not suffice since it counts float as numeric not only integers and is_int() which does not work on string numbers.

I did something similar to this

$var1 = 'string';
$var2 = '123'; 

var_dump( (int)$var1 == $var1);// boolean true 
var_dump((int)$var2 == $var2);// boolean true

 var_dump((int)$var1);//int 0
 var_dump($var1);//string 'string' (length=6)

As expected the second var dump outputs true since I expect with php’s loose comparison that the string and integer versions be equal.

However with the first, I don’t get why this is so. I have tried casting to bool and it still gives me the same result.

I have tried assigning the cast var to a new variablr and comparing the two, still the same result

Is this something I am doing wrong or it is a php bug?

I am not comparing types here. I’m actually trying to take advantage of the fact that int 0 is not equal to string 'string'.

I wrote my integer check differently so I don’t really need alternatives for that.

I did some extra checking and it turns out that 0 == 'string' is true as well. How is that possible?

***Edit 2
There are multiple correct answers below to the question. Thanks to everyone who answered.

How to&Answers:

It’s not a bug, it’s a feature. Any string can be casted to an integer, but the cast will return 0 if the string doesn’t start with an integer value. Also, when comparing an integer and a string, the string is casted to an integer and then the check is done against the two integers. Because of that rule, about just any random string is “equal” to zero. (To bypass this behavior, you should use strcmp, as it performs an explicit string comparison by casting anything passed to a string.)

To make sure I’m dealing with an integer, I would use is_numeric first, then convert the string to an int, and verify that the stringified int corresponds to the input value.

if (is_numeric($value) && strcmp((int)$value, $value) == 0)
    // $value is an integer value represented as a string


According to php.net http://php.net/manual/en/language.operators.comparison.php:

var_dump(0 == "a"); // 0 == 0 -> true

So, I think it is juggling the types, and actually casting both sides to int. Then comparing either the sum of the ascii values or the ascii values of each respective index in the string.


First of all in mathematices ‘=’ is called transitive b/c (A=B and B=C => A=C) is valid.

This is not the case with PHPs “==”!

(int)$var1 == $var1

In that case PHP will cast ‘string’ to 0 – that’s a convention.

Then ==-operator will implicitely have the second operand ‘string’ also be casted to integer -> as well 0.

That leads to true.


You made an error with your post, the correct output is this:

string(6) "string"

What happens is this:

  1. Because you cast the variable to an integer, and you compare it to an integer with a loose comparison ==, PHP will first implicitely cast the string to an integer, a more explicit but 100% equivalent form would be: if((int)$var1 == (int) $var1)
  2. See 1), the same thing applies here
  3. It prints int(0), as it should, because it fails to parse the number, it will return 0 instead.
  4. Prints string(6) "string" – as expected


If you want to compare types of variables too you should use ===.


Note: This answer is in response to a related question about the Twig template engine, that was marked as a duplicate, and redirects here.

Because the context is different, this answer is provided to those members of the SO community who may benefit from additional details specifically related to exclusively.

TL;DR: see this post How do the PHP equality (== double equals) and identity (=== triple equals) comparison operators differ?



  • Twig template engine (latest version as of Fri 2017-01-27T05:12:25)


  • DeveloperYlohEnrohK uses comparison operator in twig expression
  • DeveloperYlohEnrohK notices unexpected results when using equality comparison operator


  • Why does the equality comparison operator (==) produce unexpected results in Twig?
  • Why do the following produce different results?

    {{ dump(0 == 'somekey') }}          ==> true
    {{ dump(0|lower == 'somekey') }}    ==> false


  • Since Twig is based on PHP, the , implicit and semantics of PHP apply to Twig templates as well.
  • Unless DeveloperYlohEnrohK is intentionally and specifically leveraging the behavior of implicit type-conversion in PHP, the comparison expression will almost certainly produce counterintuitive and unexpected results.
  • This is a well-known circumstance that is described in detail in this SO post on PHP equality.
  • Solution: Just as is the case with standard PHP, unless the well-known circumstance is accounted for, using === in Twig is much less likely to produce unexpected results.


  • As of this writing, the Twig template engine does not support === in the same way as standard PHP
  • Twig does have a substitute for === using same as
  • Because of this, the treatment of this well-known circumstance differs slightly between PHP and Twig.

See also


Here’s a function that more rigorously tests for either an int or an integer string.

function isIntegerNumeric($val) {
  return (
      || (
          && is_numeric($val)
          && strpos($val, ".") === false

It’s relatively quick and avoids doing any string checking if it doesn’t have to.