As far as I know, this is the last of two issues we're encountering on a rather large Drupal 7 site running on HHVM (Facebook's Hip-Hop VM). There are two strange issues that were traced back to the line print eval('?>' . $code); which exists in the php.module file in the php_eval function as well as the rules_php_eval function of rules/modules/php.eval.inc (I'll post a related issue for rules later).
The issue manifested as the number 1 being printed after custom blocks that contained PHP code. Even though we're not explicitly calling "return" in the PHP code of the custom blocks, HHVM still seems to think we are. Perhaps the block module is doing that. Not sure. But, it seems like something is returning true, which HHVM is evaluating as a 1 and getting printed after the code that was evaluated since eval is called with the print statement.
To fix it, I simple changed:
print eval('?>' . $code);
To this:
eval('?>' . $code);
So, my question is, why is "print" being used there? It seems to just print the return value of eval if the code being evaluated returns anything. Based on the php docs for eval:
eval() returns NULL unless return is called in the evaluated code, in which case the value passed to return is returned. If there is a parse error in the evaluated code, eval() returns FALSE and execution of the following code continues normally. It is not possible to catch a parse error in eval() using set_error_handler().
What are the implications of this change? I realize this may be an issue that needs to be logged with the HHVM team, but just wanted to post here first to see if there is a scenario in which the absence of the print statement could cause an issue.
Comments
Comment #1
dcarrith commentedComment #2
dcarrith commentedComment #3
dcarrith commentedIt looks like this might be acknowledged as an HHVM issue. https://github.com/facebook/hhvm/issues/2023
However, I still wonder if the "print" is required above.
Comment #4
yaslama commentedThe issue was closed in hhvm by this commit.
Comment #5
dcam commentedIt sounds like this was fixed in HHVM. Feel free to re-open the issue if I'm mistaken.