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

Reply via email to