[php-src] Issue #8006: var_dump() should htmlspecialchars() its output

From: Date: Sun, 30 Jan 2022 14:23:27 +0000
Subject: [php-src] Issue #8006: var_dump() should htmlspecialchars() its output
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-239358@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/8006 Comment Author: KapitanOczywisty > The var_dump() function is clearly intended to support > debugging ONLY; it should not be used in a working program. In the debugging enviroment xdebug extension is often active, so the improved var_dump can be used with ease https://xdebug.org/docs/develop#display > 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. You can write a simple function (e.g. var_dump_html) or use xdebug or VarDumper - it's not that big deal. > Again, this process is cumbersome and is not well-suited to ad-hoc debugging. var_dump is a very crude way to debug the code, the xdebug integration with the IDE is intended for that, but I understand that var_dump doesn't require any setup and can be tempting. > I submit that the var_dump() function is incorrect in sending > raw string values to the browser For console uses this change would result in the same problem, but in reverse, which would be cumbersome and requires a great deal of fixing in the existing codebase. Of course var_dump could check if php is runned from browser or console, but I bet there is quite a bit of phpunit tests which will fail after such change or environments incorrectly classified as a browser. With other easy to use alternatives, there is little to no point in breaking current behavior. Is this a bug? No. There is nothing that would suggest that var_dump should return html in the documentation. It might be worth to add such notice, but not mentioning a feature should not suggest it's presence. Though It might be good idea to add a ___new___ function with html encoding.

« previous php.bugs (#239358) next »