Bug #75236 [Com]: infinite loop when printing an error-message

Edit report at https://bugs.php.net/bug.php?id=75236&edit=1 ID: 75236 Comment by: lzsiga at freemail dot c3 dot hu Reported by: lzsiga at freemail dot c3 dot hu Summary: infinite loop when printing an error-message Status: Closed Type: Bug Package: Reproducible crash Operating System: AIX, Linux PHP Version: 7.1.9 Assigned To: ajf Block user comment: N Private report: N New Comment: Thank you for your answer, so here is my next question: should I find out how to make ISO-8859-2 to be supported, could it be merged into PHP? Previous Comments: ------------------------------------------------------------------------ [2017-09-21 10:00:24] cmb@php.net PHP strings are unaware of the character encoding, so basically any character encoding is supported. How these are handled exactly depends on the respective functions/methods. For instance, the character ļ (U+013C, of course!) is not handled well when given in UTF-16BE encoding to htmlentities(): <?php var_dump(htmlentities("\x01\x3c", ENT_COMPAT, 'UTF-16BE')); ?> outputs something like: Warning: htmlentities(): charset `UTF-16BE' not supported, assuming utf-8 string(5) "
&lt;" If the $encoding parameter is not set, or simply wrong, the result may be identical, but there may not even be a warning. It is the developers responsibility to properly deal with character encodings. ------------------------------------------------------------------------ [2017-09-21 09:00:01] lzsiga at freemail dot c3 dot hu Hi, thank you all for the quick fix! Speaking of character-encodings, I'd like to ask something: does PHP support any character-seta that aren't ASCII-compatible (i.e.: there might be a byte between 0x00 and 0x7f that isn't ASCII-code, but a part of a sequence), like UCS2, UTF-16 or UTF-16? (I really hope the answer is a 'no';) ------------------------------------------------------------------------ [2017-09-20 23:06:36] ajf@php.net Automatic comment on behalf of ajf@ajf.me Revision: http://git.php.net/?p=php-src.git;a=commit;h=418f97443aa44644bdf81b96fb726518754724f5 Log: Fix bug #75236 ------------------------------------------------------------------------ [2017-09-20 22:18:48] ajf@php.net Argh, I'm sorry about this, I probably should have tested that fix more than I did. I'm looking into this now. ------------------------------------------------------------------------ [2017-09-20 22:00:39] cmb@php.net > instead of 'htmlentities' 'htmlspecialchars' should be called That can cause issues if the string is encoded differently than what the output expects. > htmlspecialchars only deals with ASCII characters like < > & ' " Applying htmlspecialchars() on an arbitrary encoding assuming it would be ASCII compatible causes issues. Consider an UTF-16 encoded ļ (U+0131). Anyhow, the behavioral change introduced by fixing bug #74725 appears to be a severe bug, since htmlspecialchars() segfaults due to infinite recursion for any unsupported default_charset, if html_errors is enabled: <?php ini_set('html_errors', true); ini_set('default_charset', 'ISO-8859-2'); htmlentities('foo', ENT_COMPAT, 'ISO-8859-2'); A possible solution might be to temporarily change the default_charset to UTF-8 while calling php_error_docref()[1], and to remove charset_hint from the message, to ensure that we're really dealing with UTF-8 (actually, ASCII) here. Andrea, could you please have a look at this issue? [1] <https://github.com/php/php-src/blob/php-7.1.9/ext/standard/html.c#L463-L464> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75236 -- Edit this bug report at https://bugs.php.net/bug.php?id=75236&edit=1