Why Does 1234 == '1234 Test' Evaluate to True

Why does 1234 == '1234 test' evaluate to true?

Because you are using the == (similarity) operator and PHP is coercing the string to an int.

To resolve it use the === (equality) operator, which checks not only if the value is the same, but also if the data type is the same, so "123" string and 123 int won't be considered equal.

in php causing false positives when variable is zero

what Mark said but to expound, 0 is a number so the == operator casts the 'parent' string to a number, which gives 0. The == operator does not care about type. So they match.

Why is this Smarty if statement always evaluating true?

Because the {x|y} syntax is a smarty shortcode for echo y(x).... where echo is significant

However, {if y|x ==4 } is the equivalent of performing bitwise or (|) on x and y (12345|count_characters is true because 12345 is true, even though count_characters would be tested as a constant and if the constant doesn't exist then as a string literal, while throwing a notice), comparing the result of that operation against 4 (true == 4 with loose-typing), and then if true, etc

Why do comparisons with Integer.valueOf(String) give different results for 127 and 128?

There's a striking difference here.

valueOf is returning an Integer object, which may have its values cached between -128 and 127. This is why the first value returns true - it's cached - and the second value returns false - 128 isn't a cached value, so you're getting two separate Integer instances.

It is important to note that you are comparing references with Integer#valueOf, and if you are comparing a value that is larger than what the cache supports, it will not evaluate to true, even if the parsed values are equivalent (case in point: Integer.valueOf(128) == Integer.valueOf(128)). You must use equals() instead.

parseInt is returning a primitive int. This is why the third value returns true - 128 == 128 is evaluated, and is of course, true.

Now, a fair bit happens to make that third result true:

An unboxing conversion occurs with respect to the equivalence operator you're using and the datatypes you have - namely, int and Integer. You're getting an Integer from valueOf on the right hand side, of course.
After the conversion, you're comparing two primitive int values. Comparison happens just as you would expect it to with respect to primitives, so you wind up comparing 128 and 128.

Why doesn't comparison with bool convert to bool in C11?

Why doesn't comparison with bool convert to bool in C11?

_Bool is the lowest rank and equality operator == specifies that its _Bool operands are promoted to int. @StoryTeller

The rank of _Bool shall be less than the rank of all other standard integer types. C11 §6.3.1.1 1

(Equality operators) If both of the operands have arithmetic type, the usual arithmetic conversions are performed. §6.5.9 4

(usual arithmetic conversions) ... the integer promotions are performed on both operands §6.3.1.8 1

(integer promotions) If an int can represent all values of the original type ... the value is converted to an int ... §6.3.1.1 2

OP's code samples did not have a "comparison with bool".

// int compared to int: false since a == 1234 and that is not equal 1
if (a == true)

Instead could have had

// int compared to _Bool: false since a == 1234 and that is not equal to 0 or 1
if (a == b)

With int == _Bool, int == short, int == signed char, the same thing occurs. The lower rank operand is promoted to int.

1) Why wasn't true defined as (bool)1? This would allow the compiler to at least output a warning.

Why? a standard committee decision of years ago. Considering true as (int)1 rather than (_Bool)1 certainly would have impacted the existing code less when _Bool was introduced. (C99). This is consistent with other sub-int constants like SHRT_MAX which is usually an int, not short. In any case, in most contexts, a promotion to int/unsigned would occur anyway before further processing - like in this compare case.

Further (_Bool)1 is not needed to allow a compiler to provide a warning. A compiler can be made that supplies a warning using various analytic tools. As (_Bool)1, it would simplify things for a compiler to provide such a warning though.

2) Why is the integer in my example not converted into a bool such that a == true would evaluate to (bool)a == true which actually would be true?

As true is an (int)1, with a == true, both operands are int. _Bool does not apply here.

2) [OP Updated] Why is the integer in my example not converted into a bool such that a == true would evaluate to (bool)a == true which actually would be true?

The top of the answer addresses this: true in an int, so (bool)a is promoted to an int before the comparison as int is higher rank than _Bool.

PHP type juggling, String == 0 and String == true

Conversion 1

When string and integer comparisons are made, the string is converted to an integer first and then the comparison is made. Since there are no leading integers in those strings they convert to zero.

Conversion 2

Any non-empty string values are boolean true.

From the manual:

The following things are considered to be empty:

"" (an empty string)
0 (0 as an integer)
0.0 (0 as a float)
"0" (0 as a string)
NULL
FALSE
array() (an empty array)
$var; (a variable declared, but without a value)

Why Does 1234 == '1234 Test' Evaluate to True