Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inlined comparsion showcases weird behaviour #25

Open
IngwiePhoenix opened this issue Nov 20, 2015 · 1 comment
Open

Inlined comparsion showcases weird behaviour #25

IngwiePhoenix opened this issue Nov 20, 2015 · 1 comment

Comments

@IngwiePhoenix
Copy link

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. :)

@asmblah
Copy link
Owner

asmblah commented Nov 22, 2015

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants