ID: 42461
User updated by: theblazingangel at aol dot com
Reported By: theblazingangel at aol dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Win XP
PHP Version: 5.2.3
New Comment:
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...
Previous Comments:
------------------------------------------------------------------------
[2007-08-28 21:35:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
------------------------------------------------------------------------
[2007-08-28 15:01:10] 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>
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=42461&edit=1
