ID: 47494 Updated by: j...@php.net Reported By: philipp dot feigl at gmail dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: CentOS5 PHP Version: 5.2.8 New Comment:
It's intentional. If you disagree, please ask s...@php.net why it is like this (I once reverted that :) Previous Comments: ------------------------------------------------------------------------ [2009-02-24 13:57:32] philipp dot feigl at gmail dot com Description: ------------ When using htmlspecialchars with a invalid multibyte string and using UTF-8 as encoding, there are two possible outcomes based on the "display_errors" ini setting: 1. display_errors=1 => empty string is returned 2. display_errors=0 => E_WARNING is thrown This is exactly what the code states. Can be viewed in http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?view=markup on line 1147 However this is VERY confusing as a developer point of view. As I have display_errors always set to "1" for debugging purposes, I never realized, one of our locale strings was corrupt, as it was just emptied out. Now in the production environment, our error handler terminates the script because of the E_WARNING beeing thrown. While both of the ways (empty string / error) are acceptable for me - because ofcourse the input string is invalid, it is very confusing to have different behaviors of PHP based on the display_errors setting. Reproduce code: --------------- echo 'a' . htmlspecialchars(substr(utf8_encode('aĆ¼'), 0, 2), ENT_QUOTES, 'UTF-8') . 'b'; Expected result: ---------------- Either 'ab' Or PHP E_WARNING However not both based on display_errors Actual result: -------------- display_errors=1 => 'ab' display_errors=0 => E_WARNING ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=47494&edit=1