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

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.

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 <PRE></PRE> around the print_r if you need to view it correctly.  Nothing's wrong with the "tool" as it works now.

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.

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.

Thank you for those hints.
As said before, I was not aware that existing CLI code
might be broken by my request.