|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2007-08-28 15:01 UTC] theblazingangel at aol dot com
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>
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sun May 19 03:01:33 2024 UTC |
ok, i agree that it's not really a "bug", but perhaps it could be taken as a suggestion? is it necessary that under such a situation that it causes an error? i mean, lets look at some examples where the ?> after a comment might be taken literally: 1) <?php echo 'something'; //comment ?> this is a case where it should definately be taken literally 2) <?php if (1==1) { echo 'something'; } //comment ?> again, should be taken literally 3) <?php if (1==1) { echo 'something'; //comment ?> } ?> here, this will cause an error. the first ?> is taken literally, which prematurely ends the if. if it saw that the brackets handn't finished, it could perhaps *attempt* to leave it as part of the comment, and see if the parser can continue on like that... 4) <?php if (1==1) echo 'something'; //comment ?> ?> well, here it's a little confusing i suppose, do you treat the first as a comment, or the second as html... :( i hope the developers could just take a note of this incase it's at all possible to allow ?> in // comments under certain conditions. it seems like a bit of an anomaly to me for //preg_match('/^(?>c|h)at$/', 'cat', $matches); to fail as a parse error, it seems something easy to make a mistake with, perhaps hard to diagnose - took me a while to find it and i consider myself pretty good with php - note that the fact that it doesn't report the line number it occured on doesn't help diagnostics! *** if not, perhaps at least something could come of this...: 1) a note in the regex documentation section besides the usage of (?>), to remind users that commenting out a line containing it with // will cause an error 2) perhaps the parse engine could recognise potential occurances of this problem and report them - if an error occurs, and the parser "thinks" it could be because of a rogue ?>, it could inform the user with a notice...