#42461 [NEW]: //?> causing parse errors

From: Date: Tue, 28 Aug 2007 15:01:10 +0000
Subject: #42461 [NEW]: //?> causing parse errors
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-116771@lists.php.net to get a copy of this message
From: theblazingangel at aol dot com Operating system: Win XP PHP version: 5.2.3 PHP Bug Type: *Compile Issues Bug description: //?> causing parse errors Description: ------------ //?> (with anything or nothing in-between // and ?>) can cause parse errors. i noticed this while constructing regex patterns, when i used // to comment out lines containing >?, it gave me this error: Parse error: syntax error, unexpected T_VARIABLE, expecting T_FUNCTION in <file> on line 466 it can be extremely confusing when you suddenly get this error after commenting out a line like: //preg_match_all("/(?:^|[ ]+)(?!\-)\+?(?:(?>\"|\')(?=((?:[ ]\\1|$\\1)+))\\1|([^ ]+))(?:|(?=[ ])|$)/s", $search, $matches); i get that in a situation like the following, ?> should be taken as the end of the php code: <?php echo $data //print data ?> however, in the situation i was in, (where commenting out the line resulted in the ?> being taken as the php terminator, and therefore causing an error because the if/loop/function/class/etc hadn't finished), shouldn't the php parser, before reporting the error, attempt to continue as if the ?> was part of the comment? the solution is to use /**/ rather than //, but it seems counter intuitive to me that it fails in the frst place in such a situation... Reproduce code: --------------- <?php if(1==1) { //?> } ?> Expected result: ---------------- for example code: a blank page for the code i discovered it in: it should have continued with no error Actual result: -------------- with the example: Parse error: syntax error, unexpected $end in <file> on line 8 with the code in the description, in the file i used it in (a wordpress plugin): Parse error: syntax error, unexpected T_VARIABLE, expecting T_FUNCTION in <file> on line <x> -- Edit bug report at http://bugs.php.net/?id=42461&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42461&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42461&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42461&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42461&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42461&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42461&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=42461&r=needscript Try newer version: http://bugs.php.net/fix.php?id=42461&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42461&r=support Expected behavior: http://bugs.php.net/fix.php?id=42461&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42461&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42461&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42461&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42461&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42461&r=dst IIS Stability: http://bugs.php.net/fix.php?id=42461&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42461&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42461&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42461&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=42461&r=mysqlcfg

« previous php.bugs (#116771) next »