I can confirm this issue. It happens for all unsupported "charsets", i.e.
for those that htmlentities() would throw a respective warning. See
<https://github.com/php/php-src/blob/php-7.1.9/ext/standard/html.c#L448-L467>.

> The problem could be solved if htmlentities didn't verify UTF8-validity and
> silently ignored 'charset' parameter.

That would cause other issues, though.

Well, yes, my fault; what I should have suggested is that instead of 'htmlentities' 'htmlspecialchars' should be called, with hardcoded 'charset='ISO-8859-1' (or 'ASCII' if there is such an option -- htmlspecialchars only deals with ASCII characters like < > & ' " )

> 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>

Argh, I'm sorry about this, I probably should have tested that fix more than I did.

I'm looking into this now.

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';)

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.

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?

Adding htmlentities() support for ISO-8859-2 shouldn't be hard[1], but I'm not
sure whether that would be welcome. I suggest to ask on internals@lists.php.net
first.

[1] <https://lxr.room11.org/xref/php-src%40master/ext/standard/html_tables.h#44>