asmblah/uniter

Inlined comparsion showcases weird behaviour

Opened this issue · 1 comments

Within my last test cases, I used this line:

echo "PHP_EOL: [".(PHP_EOL == "\n" ? "Yes" : "No")."]";

... but actually, it would print

PHP_EOL: []

Obviously, that would only be the case if the expression would only be evaluated by its first half:

0 -> Number(0) -> String("")
1 -> Number(1) -> String("1")

That, at least, would totally adhere to the PHP way of handling this.

However, replacing the above expression with the following, yields a totally different result:

$hasEol = (PHP_EOL == "\n");
echo "PHP_EOL: [".($hasEol ? "Yes":"No")."]\n";

In this one, the output actually reads

PHP_EOL: [Yes]

Note: This time, the second half of the inlined if-statement was evaluated correctly.

if(true) String("Yes")
else String("No")

...whilst in the first expression, the bool was converted directly into a string-ish expression.

This behaviour was encountered totally randomly, but it might be something to investigate. :)

Hi @IngwiePhoenix, thanks for reporting this. It was actually part of a bigger set of operator precedence issues, so it was a good spot!

This should now be fixed in PHPToAST v3.0.0/PHPToJS v3.0.0/PHPCore v3.4.0/PHPRuntime v4.1.0/Uniter v2.5.0.

Cheers!