#42461 [NEW]: //?> causing parse errors
| From: | theblazingangel at aol dot com | 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