Bug #53298 [Bgs]: // $msg_text = '?...';
Edit report at http://bugs.php.net/bug.php?id=53298edit=1
ID: 53298
User updated by:jost dot boekemeier at googlemail dot com
Reported by:jost dot boekemeier at googlemail dot com
Summary:// $msg_text = '?...';
Status: Bogus
Type: Bug
Package:*General Issues
Operating System: any
PHP Version:5.2.14
Block user comment: N
Private report: N
New Comment:
@jost dot boekemeier: I'll preface this comment with I'm just a
regular
PHP user, not a PHP org member.
Then please do not comment other one`s bug reports.
This bug report is about a change in the php parser. It was working
perfectly
until someone changed it to not recognize ? within strings. The bug is
that
he did not make the same change for strings in single line comments.
There
is nothing to discuss about. The person who made the change clearly
wrote a
bug.
Your comments about multi line comments and IDE are offtopic here.
Please
open a new support request for that. Thank you.
Previous Comments:
[2010-11-18 03:41:06] bastard dot internets at gmail dot com
@jost dot boekemeier: I'll preface this comment with I'm just a
regular PHP user, not a PHP org member.
Changing the // behavior would break the usage in in-line php, shown on
the 2nd example on the doc page. Something like the following would no
longer work...
pThis is a paragraph about ?php echo $subject; // important comment
here ?./p
Looks ugly here, but with any IDE, the color-coding makes it all pretty
intelligible. The doc page is pretty clear about this comment usage.
The workaround to comment out any entire block containing any ?
symbol would be to use the /* */ symbols instead. Of course this goes
against convenience and habit, and as other users have noted, this
breaks lines with */ appearing anywhere (ie. regex strings, nested
comments, etc). But fixing -those- problems would break things
elsewhere, like in this example of sourcecode documentation...
function do_something(/* integer */ $some_int, /* string */ $some_str)
{/* do something */}
This report seems more like a feature request. I'd vote for something
like skipping the in-comment PHP mode escape if the // symbol doesn't
appear on a same line as any opening PHP tag. Though I'm sure devs can
think of a better solution.
[2010-11-14 14:38:58] jost dot boekemeier at googlemail dot com
fel...@php.net, thank you very much for taking the time to comment my
request, even though you haven't understood it.
1. commenting out a valid variable definition should not cause the PHP
parser to *suddenly* parse the definition!
2. this is completely unexpected, even after reading the documentation
Please either fix this bug. Change the PHP parser to handle
$var = val?ue;
and
// $var = val?ue;
equally: The parser should either stop at the ? or not. For example if
you force the programmer to always write val.?ue, the problem
vanishes.
The current behaviour means that you can expose the contents of an
existing PHP file (including database passwords) by commenting out a
simple variable definition. -- Line-comments can be problematic, but it
shouldn't have such a drastic effect that the script returns
unevaluated.
Or please clearly document this bug, so that programmers do not use
//-style comments to comment-out variable definitions.
[2010-11-12 21:43:23] fel...@php.net
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
[2010-11-12 20:39:36] bastard dot internets at gmail dot com
? is meant to break out of PHP when encountered in a single-line
comment (see
http://www.php.net/manual/en/language.basic-syntax.comments.php).
[2010-11-12 12:19:20] jost dot boekemeier at googlemail dot com
corrected mail address
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53298
--
Edit this bug report at http://bugs.php.net/bug.php?id=53298edit=1
Bug #53298 [Bgs]: // $msg_text = '?...';
Edit report at http://bugs.php.net/bug.php?id=53298edit=1 ID: 53298 User updated by:jost dot boekemeier at googlemail dot com Reported by:jost dot boekemeier at googlemail dot com Summary:// $msg_text = '?...'; Status: Bogus Type: Bug Package:*General Issues Operating System: any PHP Version:5.2.14 Block user comment: N New Comment: fel...@php.net, thank you very much for taking the time to comment my request, even though you haven't understood it. 1. commenting out a valid variable definition should not cause the PHP parser to *suddenly* parse the definition! 2. this is completely unexpected, even after reading the documentation Please either fix this bug. Change the PHP parser to handle $var = val?ue; and // $var = val?ue; equally: The parser should either stop at the ? or not. For example if you force the programmer to always write val.?ue, the problem vanishes. The current behaviour means that you can expose the contents of an existing PHP file (including database passwords) by commenting out a simple variable definition. -- Line-comments can be problematic, but it shouldn't have such a drastic effect that the script returns unevaluated. Or please clearly document this bug, so that programmers do not use //-style comments to comment-out variable definitions. Previous Comments: [2010-11-12 21:43:23] fel...@php.net 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 [2010-11-12 20:39:36] bastard dot internets at gmail dot com ? is meant to break out of PHP when encountered in a single-line comment (see http://www.php.net/manual/en/language.basic-syntax.comments.php). [2010-11-12 12:19:20] jost dot boekemeier at googlemail dot com corrected mail address [2010-11-12 12:08:24] jost dot boekemeier at googlemail dot com Description: PHP Parser doesn't handle comments as such ?php echo 1+2; // $msg_text = '?RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0'; echo 1+2; should print 33, and not print the script unevaluated. Test script: --- ?php echo 1+2; // $msg_text = '?RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0'; echo 1+2; Expected result: 33 Actual result: -- 3RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0'; echo 1+2; -- Edit this bug report at http://bugs.php.net/bug.php?id=53298edit=1
Bug #53298 [Opn]: // $msg_text = '?...';
Edit report at http://bugs.php.net/bug.php?id=53298edit=1 ID: 53298 User updated by:jost dot boekemeier at googlemail dot com Reported by:jost dot boekemeier at googlemail dot com Summary:// $msg_text = '?...'; Status: Open Type: Bug Package:*General Issues Operating System: any PHP Version:5.2.14 Block user comment: N New Comment: corrected mail address Previous Comments: [2010-11-12 12:08:24] jost dot boekemeier at googlemail dot com Description: PHP Parser doesn't handle comments as such ?php echo 1+2; // $msg_text = '?RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0'; echo 1+2; should print 33, and not print the script unevaluated. Test script: --- ?php echo 1+2; // $msg_text = '?RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0'; echo 1+2; Expected result: 33 Actual result: -- 3RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0'; echo 1+2; -- Edit this bug report at http://bugs.php.net/bug.php?id=53298edit=1
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
User updated by: jost dot boekemeier at googlemail dot com
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
Right. In particular:
?php // pjb library
function autoload_pjb($x) {echo pjb ; return false;}
spl_autoload_register(autoload_pjb);
if(function_exists(__autoload)) spl_autoload_register(__autoload);
?
?php // joomla library
function __autoload($x) {echo joomla ; return false;}
?
?php // application
require(pjb.php);
require(joomla.php);
@new Foo();
?
Please see the link posted with the bug report for all the details.
However, I think neither the user nor joomla nor I have to invent
strange
workarounds for bugs in the php implementation. Any new introduced PHP
feature
must be compatible with earlier PHP features, unless the earlier
features have been
deprecated and a clear migration path exists.
The old __autoload is neither deprecated nor is spl_autoload_register
compatible with
it. Whoever wrote it and the comment This is because
spl_autoload_register() will
effectively replace the engine cache fo the __autoload function by
either
spl_autoload() or spl_autoload_call(). wrote a bug.
Thus, calling spl_autoload_register() replaces __autoload()
If spl_autoload_register is intended to replace the old __autoload
machinery, the old
__autoload should have been deprecated and a clear migration path
should have
been given to those using it.
Previous Comments:
[2009-09-23 07:23:07] sjo...@php.net
So the problem occurs with:
include('spl_autoload_register.php'); // uses spl_autoload_register
include('autoload.php'); // defines __autoload
[2009-09-22 17:39:32] jost dot boekemeier at googlemail dot com
if (function_exists(__autoload)) spl_autoload_register(__
autoload)
Doesn't work. In line 7 __autoload is not yet defined.
Note that every line in the given example comes from a separate
include()d php
library.
This is a link-time problem which only php can resolve: it must save a
legacy
__autoload handler before creating the spl_autoload stack and call the
legacy
autoload after all other registered spl_autoload hooks.
[2009-09-22 17:26:38] sjo...@php.net
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists(__autoload)) spl_autoload_register(__autoload);
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49618
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
User updated by: jost dot boekemeier at googlemail dot com
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
Previous Comments:
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
User updated by: jost dot boekemeier at googlemail dot com
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
if (function_exists(__autoload)) spl_autoload_register(__
autoload)
Doesn't work. In line 7 __autoload is not yet defined.
Note that every line in the given example comes from a separate
include()d php
library.
This is a link-time problem which only php can resolve: it must save a
legacy
__autoload handler before creating the spl_autoload stack and call the
legacy
autoload after all other registered spl_autoload hooks.
Previous Comments:
[2009-09-22 17:26:38] sjo...@php.net
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists(__autoload)) spl_autoload_register(__autoload);
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49618 [NEW]: spl_autoload_register destroys __autoload hook
From: jost dot boekemeier at googlemail dot com
Operating system: Any
PHP version: 5.2.11
PHP Bug Type: SPL related
Bug description: spl_autoload_register destroys __autoload hook
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit bug report at http://bugs.php.net/?id=49618edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49618r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49618r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49618r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49618r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49618r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49618r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49618r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49618r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49618r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49618r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49618r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49618r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49618r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49618r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49618r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49618r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49618r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49618r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49618r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49618r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49618r=mysqlcfg
