[php-src] Issue #8006: var_dump() should htmlspecialchars() its output
| From: | canajun2eh | Date: | Sun, 30 Jan 2022 13:00:06 +0000 |
| Subject: | [php-src] Issue #8006: var_dump() should htmlspecialchars() its output | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-239357@lists.php.net to get a copy of this message | ||
Issue: https://github.com/php/php-src/issues/8006
Comment Author: canajun2eh
I disagree.
You are incorrect in changing the title and the class of this issue. Please restore the original
title and make this a "bug" again. Your discussion about the string value possibly
containing something that is eventually rendered as
ü is not relevant.
The var_dump() function is clearly intended to support debugging ONLY; it should not be
used in a working program. The PHP manual is quite clear on this: "This function displays
structured information ..." and "As with anything that outputs its result directly to the
browser, the output-control functions can be used to capture the output of this function, and save
it in a string (for example)."
The PHP language has no built-in tool that permits the programmer to determine the _raw_ value of a
string. Neither print nor echo do this; they send the _raw_ string value
to the browser which then takes action as determined by the text it has received. The
var_dump() function does exactly the same thing: it sends the _raw_ string value to the
browser.
I realize that the output control functions can be used to capture the result of the
var_dump() function to a string, which can then undergo a transformation using
str_replace(array('&', '<', '>'),
array('&', '>', '<'), $capturedText); The
transformed captured text can then be sent to the browser. This process is cumbersome and requires
a great deal of before-the-fact planning. There is also no guarantee that captured text that is not
part of a string value will not be transformed. The output control functions are therefore not
suited to ad-hoc debugging.
I also realize that the browser's "View page source" (or whatever your favourite
browser calls this) function can be used to determine the actual string value. Again, this process
is cumbersome and is not well-suited to ad-hoc debugging.
I submit that the var_dump() function is incorrect in sending raw string values to the
browser; it should be performing a transformation of these string values using an equivalent of the
str_replace() function mentioned above. Of course, the length of the string values
should be calculated before the transformation takes place.