[PHP-BUG] Bug #63467 [NEW]: is_callable returns false for public function inherited from parent
From: martijn dot otto at copernica dot com
Operating system: linux
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Bug
Bug description:is_callable returns false for public function inherited from
parent
Description:
When calling is_callible on a public function inherited from a parent, it
will
return false.
Test script:
---
class a
{
public function bla() {}
}
class b extends a
{
}
$b = new b;
var_dump(is_callable($b, 'bla'));
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at https://bugs.php.net/bug.php?id=63467edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63467r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63467r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63467r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63467r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63467r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63467r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63467r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63467r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63467r=support
Expected behavior: https://bugs.php.net/fix.php?id=63467r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63467r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63467r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63467r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63467r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63467r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63467r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63467r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63467r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63467r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63467r=mysqlcfg
#51044 [NEW]: errorInfo should allow for returning msg only
From: otto dot wyss at orpatec dot ch Operating system: Irrelevant PHP version: 5.2.12 PHP Bug Type: Feature/Change Request Bug description: errorInfo should allow for returning msg only Description: Currently PDO::errorInfo returns an array (SQLSTATE, driver specific code, message) but almost ever only the message is interesting. Therefore I propose to expand the API to add an obtional array index, if present only the indexed information will be returned. The return type probably has to be changed to mixed as well. Current calls without parameter return the current array, future calls i.e. errorInfo (2) will only return the text message as a string. -- Edit bug report at http://bugs.php.net/?id=51044edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51044r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51044r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51044r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51044r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51044r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51044r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51044r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51044r=needscript Try newer version: http://bugs.php.net/fix.php?id=51044r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51044r=support Expected behavior: http://bugs.php.net/fix.php?id=51044r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51044r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51044r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51044r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51044r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51044r=dst IIS Stability: http://bugs.php.net/fix.php?id=51044r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51044r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51044r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51044r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51044r=mysqlcfg
#31402 [Fbk-Opn]: unserialize creates a field containing a reference when it should not
ID: 31402
User updated by: otto at efficiency-online dot nl
Reported By: otto at efficiency-online dot nl
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: OpenBSD 3.6
PHP Version: 4.3.10
New Comment:
I'm getting the same, wrong, results with
php4-STABLE-200501171730.
-Otto
Previous Comments:
[2005-01-17 18:37:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-01-04 09:22:55] otto at efficiency-online dot nl
Description:
An object having a field initialized to a element of an array in the
same object is transformed into a reference after unserializing. I had
a session object exposing this problem and managed to create a code
snippet exposing the problem. After the assignment to the field $y-B,
the array should not have changed, but it is changed.
It looks like $y-B has become a reference to $y-A[1] after the
unserialize call. This is a regression wrt to 4.3.9 and might be
related to bug Bug #31213.
Reproduce code:
---
?php
class X {
var $i;
function X($i) {
$this-i = $i;
}
}
class Y {
var $A = array();
var $B;
function x() {
$this-A[1] = new X(1);
$this-A[2] = new X(2);
$this-B = $this-A[1];
}
}
$x = new Y();
$x-x();
echo original object:\n;
print_r($x);
$ser = serialize($x);
$y = unserialize($ser);
echo after unserialize:\n;
print_r($y);
$y-B = $y-A[2];
echo after assignment:\n;
print_r($y);
?
Expected result:
// result with 4.3.9
original object:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after unserialize:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after assignment:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 2
)
)
Actual result:
--
// result with 4.3.10
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after unserialize:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after assignment:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 2
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 2
)
)
--
Edit this bug report at http://bugs.php.net/?id=31402edit=1
#31402 [NEW]: unserialize creates a field containing a reference when it should not
From: otto at efficiency-online dot nl
Operating system: OpenBSD 3.6
PHP version: 4.3.10
PHP Bug Type: Scripting Engine problem
Bug description: unserialize creates a field containing a reference when it
should not
Description:
An object having a field initialized to a element of an array in the
same object is transformed into a reference after unserializing. I had a
session object exposing this problem and managed to create a code snippet
exposing the problem. After the assignment to the field $y-B, the array
should not have changed, but it is changed.
It looks like $y-B has become a reference to $y-A[1] after the
unserialize call. This is a regression wrt to 4.3.9 and might be related
to bug Bug #31213.
Reproduce code:
---
?php
class X {
var $i;
function X($i) {
$this-i = $i;
}
}
class Y {
var $A = array();
var $B;
function x() {
$this-A[1] = new X(1);
$this-A[2] = new X(2);
$this-B = $this-A[1];
}
}
$x = new Y();
$x-x();
echo original object:\n;
print_r($x);
$ser = serialize($x);
$y = unserialize($ser);
echo after unserialize:\n;
print_r($y);
$y-B = $y-A[2];
echo after assignment:\n;
print_r($y);
?
Expected result:
// result with 4.3.9
original object:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after unserialize:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after assignment:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 2
)
)
Actual result:
--
// result with 4.3.10
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after unserialize:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 1
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 1
)
)
after assignment:
y Object
(
[A] = Array
(
[1] = x Object
(
[i] = 2
)
[2] = x Object
(
[i] = 2
)
)
[B] = x Object
(
[i] = 2
)
)
--
Edit bug report at http://bugs.php.net/?id=31402edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31402r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31402r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31402r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31402r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31402r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31402r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31402r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31402r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31402r=support
Expected behavior: http://bugs.php.net/fix.php?id=31402r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31402r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31402r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31402r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31402r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31402r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31402r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31402r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31402r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31402r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31402r=mysqlcfg
#25269 [NEW]: Output to mail ends with '/html' in mailform
From: otto at wikkelsoe dot dk Operating system: Windows 2000 Advanced Server PHP version: 4.3.3 PHP Bug Type: Mail related Bug description: Output to mail ends with '/html' in mailform Description: Upgrading from 4.3.2 results in following error: Output to mail ends with '/html' visibile in mailform. No errors in the phperror.log. -- Edit bug report at http://bugs.php.net/?id=25269edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25269r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25269r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25269r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25269r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25269r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25269r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25269r=support Expected behavior: http://bugs.php.net/fix.php?id=25269r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25269r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25269r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25269r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25269r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25269r=dst IIS Stability: http://bugs.php.net/fix.php?id=25269r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25269r=gnused
#25269 [Fbk-Opn]: Output to mail ends with '/html' in mailform
ID: 25269
User updated by: otto at wikkelsoe dot dk
Reported By: otto at wikkelsoe dot dk
-Status: Feedback
+Status: Open
Bug Type: Mail related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.3.3
New Comment:
There is no changes in my mailforms. I upgraded from 4.3.2 to 4.3.3,
copied php4ts.dll 4.3.3.3 to system32, edited the php.ini. The error
occured. Then I used the php.ini from 4.3.2, but the error was still
there. Then I reinstalled 4.3.2, and all worked well.
Some of the code is here:
?php
include (include/confmail.inc);
$design = htmlheadtitle$book/title
/headbody
table width=\600\ border=\1\ cellspacing=\0\ cellpadding=\1\
tr
td$navn/td
td$newnavn/td
/tr
tr
td$question/td
td$bemaerk/td
/tr
tr
td class=\ref\ colspan=\2\$mailsenderversion
$developersign/td
/tr
/table
/body/html;
if ($f_navn and $newnavn ) {
mail($reciever, $subject, $design, $headers);
header(Location:tak.php);
} else {
header(Location:fejl.php);
}
?
Previous Comments:
[2003-08-27 12:34:47] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2003-08-27 11:35:07] [EMAIL PROTECTED]
Some weird user error, please ask this kind of questions on
[EMAIL PROTECTED]
[2003-08-27 10:25:58] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2003-08-27 06:45:54] otto at wikkelsoe dot dk
Description:
Upgrading from 4.3.2 results in following error:
Output to mail ends with '/html' visibile in mailform.
No errors in the phperror.log.
--
Edit this bug report at http://bugs.php.net/?id=25269edit=1
#20310 [Com]: print_r should apply htmlspecialchars
ID: 20310
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Won\'t fix
Bug Type: Feature/Change Request
Operating System: SunOS
PHP Version: 4.2.2
New Comment:
Thank you for those hints.
As said before, I was not aware that existing CLI code
might be broken by my request.
Previous Comments:
[2002-11-08 13:47:02] [EMAIL PROTECTED]
Look - it's really simple:
?php
function ob_smart_html_handler($string)
{
$string = (isset($_SERVER['REMOTE_ADDR'])) ?
htmlspecialchars($string) : $string;
return $string;
}
// create $var here
ob_start('ob_smart_html_handler');
print_r($var);
ob_end_flush();
?
Additionally, using 4.3.0 (slightly different output):
?php
print(htmlspecialchars(var_export($var, TRUE)));
?
Now - those few lines of 'extra' code, simply don't warrant a change in
behavior, that has the potential to break CLI code.
[2002-11-08 09:24:59] [EMAIL PROTECTED]
Enclosing print_r with pre and /pre does not help!
This is exactly what I demonstrate in
http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php.
I was not aware that PHP can also be used without a HTML
context; so I am not sure what to suggest. Could print_r
determine whether it is writing to a HTML source and act accordingly?
In any case, as it stands currently, print_r is akin to
a time-bomb in unsuspecting authors' HTML pages.
[2002-11-08 08:48:16] [EMAIL PROTECTED]
Just a quick comment on this (and why I think it should stay as it
is):
I use print_r both in online (Web-based) and offline scripting.
Changing print_r to output html characters would screw things up for
those people that use PHP for more than just a web language.
That being said, if you want to use the debugging tool, just use
lt;PREgt;lt;/PREgt; around the print_r if you need to view it
correctly. Nothing's wrong with the tool as it works now.
[2002-11-08 08:36:21] [EMAIL PROTECTED]
Just because print_r is a debuggung tool,
it shold not introduce additional bugs into the HTML code!
But as it is, it will
- insert a HTML tag whenever it should report
a less-than csign,
- insert a HTML entity whenever it should report
an ampersand sign,
- spoil the whole HTML syntax, whenever it simply
should report a double-quote sign.
This renders print_r rather a dangerous (if not
to say: unusable) tool.
Please revert the status of Bug #20310 to open,
or perhaps to feature-request.
[2002-11-08 08:16:28] [EMAIL PROTECTED]
print_r is just a debugging tool, I see no reason to have
htmlspecialchars applied to it. Also, you can do this yourself quite
easily by using output buffers if you _really_ need this.
Derick
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/20310
--
Edit this bug report at http://bugs.php.net/?id=20310edit=1
#20308 [NEW]: parse_url does not understand the Mailto scheme
From: [EMAIL PROTECTED]
Operating system: SunOS
PHP version: 4.2.2
PHP Bug Type: URL related
Bug description: parse_url does not understand the Mailto scheme
parse_url('mailto:Otto.Stolz;uni-konstanz.de')
yields:
array( ['scheme'] = 'mailto'
['path'] = '[EMAIL PROTECTED]'
)
According
to http://www.zvon.org/tmRFC/RFC2368/Output/chapter2.html
and http://www.zvon.org/tmRFC/RFC2822/Output/chapter3.html#sub4,
it should rather yield:
array( ['scheme'] = 'mailto'
['host'] = 'uni-konstanz.de'
['user'] = 'Otto.Stolz'
)
A test page can be found at
http://www.rz.uni-konstanz.de/Antivirus/tests/parse_url.php,
the pertinent PHP source at
http://www.rz.uni-konstanz.de/Antivirus/tests/parse_url.txt.
--
Edit bug report at http://bugs.php.net/?id=20308edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20308r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20308r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20308r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20308r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20308r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20308r=support
Expected behavior: http://bugs.php.net/fix.php?id=20308r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20308r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20308r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20308r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20308r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20308r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20308r=isapi
#20310 [NEW]: print_r should apply htmlspecialchars
From: [EMAIL PROTECTED] Operating system: SunOS PHP version: 4.2.2 PHP Bug Type: Variables related Bug description: print_r should apply htmlspecialchars print_r writes directly to php://output, hence its output should comply with HTML syntax rules. However, print_r will issue non-compliant code, or generate spurious entities, whenever a variable contains an HTML special character. Hence, print_r should apply htmlspecialchars to all strings it is going to write to php://output. Try the demo at http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php with Netscape 6, or Opera 6, as IE 6 will not reveal all the surprises I've hidden therein ;-) The pertinent PHP source can be seen at http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.txt. -- Edit bug report at http://bugs.php.net/?id=20310edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20310r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20310r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20310r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20310r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20310r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20310r=support Expected behavior: http://bugs.php.net/fix.php?id=20310r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20310r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20310r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20310r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20310r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20310r=dst IIS Stability: http://bugs.php.net/fix.php?id=20310r=isapi
#20310 [Com]: print_r should apply htmlspecialchars
ID: 20310 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Variables related Operating System: SunOS PHP Version: 4.2.2 New Comment: Just because print_r is a debuggung tool, it shold not introduce additional bugs into the HTML code! But as it is, it will - insert a HTML tag whenever it should report a less-than csign, - insert a HTML entity whenever it should report an ampersand sign, - spoil the whole HTML syntax, whenever it simply should report a double-quote sign. This renders print_r rather a dangerous (if not to say: unusable) tool. Please revert the status of Bug #20310 to open, or perhaps to feature-request. Previous Comments: [2002-11-08 08:16:28] [EMAIL PROTECTED] print_r is just a debugging tool, I see no reason to have htmlspecialchars applied to it. Also, you can do this yourself quite easily by using output buffers if you _really_ need this. Derick [2002-11-08 08:01:37] [EMAIL PROTECTED] print_r writes directly to php://output, hence its output should comply with HTML syntax rules. However, print_r will issue non-compliant code, or generate spurious entities, whenever a variable contains an HTML special character. Hence, print_r should apply htmlspecialchars to all strings it is going to write to php://output. Try the demo at http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php with Netscape 6, or Opera 6, as IE 6 will not reveal all the surprises I've hidden therein ;-) The pertinent PHP source can be seen at http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.txt. -- Edit this bug report at http://bugs.php.net/?id=20310edit=1
#20310 [Com]: print_r should apply htmlspecialchars
ID: 20310 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Variables related Operating System: SunOS PHP Version: 4.2.2 New Comment: Enclosing print_r with pre and /pre does not help! This is exactly what I demonstrate in http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php. I was not aware that PHP can also be used without a HTML context; so I am not sure what to suggest. Could print_r determine whether it is writing to a HTML source and act accordingly? In any case, as it stands currently, print_r is akin to a time-bomb in unsuspecting authors' HTML pages. Previous Comments: [2002-11-08 08:48:16] [EMAIL PROTECTED] Just a quick comment on this (and why I think it should stay as it is): I use print_r both in online (Web-based) and offline scripting. Changing print_r to output html characters would screw things up for those people that use PHP for more than just a web language. That being said, if you want to use the debugging tool, just use lt;PREgt;lt;/PREgt; around the print_r if you need to view it correctly. Nothing's wrong with the tool as it works now. [2002-11-08 08:36:21] [EMAIL PROTECTED] Just because print_r is a debuggung tool, it shold not introduce additional bugs into the HTML code! But as it is, it will - insert a HTML tag whenever it should report a less-than csign, - insert a HTML entity whenever it should report an ampersand sign, - spoil the whole HTML syntax, whenever it simply should report a double-quote sign. This renders print_r rather a dangerous (if not to say: unusable) tool. Please revert the status of Bug #20310 to open, or perhaps to feature-request. [2002-11-08 08:16:28] [EMAIL PROTECTED] print_r is just a debugging tool, I see no reason to have htmlspecialchars applied to it. Also, you can do this yourself quite easily by using output buffers if you _really_ need this. Derick [2002-11-08 08:01:37] [EMAIL PROTECTED] print_r writes directly to php://output, hence its output should comply with HTML syntax rules. However, print_r will issue non-compliant code, or generate spurious entities, whenever a variable contains an HTML special character. Hence, print_r should apply htmlspecialchars to all strings it is going to write to php://output. Try the demo at http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php with Netscape 6, or Opera 6, as IE 6 will not reveal all the surprises I've hidden therein ;-) The pertinent PHP source can be seen at http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.txt. -- Edit this bug report at http://bugs.php.net/?id=20310edit=1
#20287 [NEW]: order by syntax problem
From: [EMAIL PROTECTED] Operating system: Win98/MySQL PHP version: 4.2.1 PHP Bug Type: MySQL related Bug description: order by syntax problem In the PHProjekt module contacts_view.php I wanted to sort the contacts list by firma and then by nachname. I changed all instances of $sort = nachname; to $sort = firma, nachname; (note the space between arguments) When modifying or creating a contact, and then returning to the contacts list I get the error message: You have an error in your SQL syntax near 'ASC' at line 1 I then removed the space like this: $sort = firma,nachname; (no space) This looks like a MySQL problem, but is it possible that PHP and/or PHProjekt handles the space character to cause the error? -- Edit bug report at http://bugs.php.net/?id=20287edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20287r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20287r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20287r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20287r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20287r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20287r=support Expected behavior: http://bugs.php.net/fix.php?id=20287r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20287r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20287r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20287r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20287r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20287r=dst IIS Stability: http://bugs.php.net/fix.php?id=20287r=isapi
