go to bug id or search bugs for
Printing an error message with settings 'html_errors=true' and 'default_charset=ISO-8859-2' leads to infinite loop.
Components of the loop:
determine_charset -> php_error_docref0 -> php_verror -> php_escape_html_entities -> php_escape_html_entities_ex -> determine_charset
This bug was introduced in version 7.1.9, main/main.c line 765
before: replace_buffer = php_escape_html_entities((unsigned char*)buffer, buffer_len, 0, ENT_COMPAT, NULL);
after: php_escape_html_entities((unsigned char*)buffer, buffer_len, 0, ENT_COMPAT, SG(default_charset));
(A note: The problem could be solved if htmlentities didn't verify UTF8-validity and silently ignored 'charset' parameter. See also: https://bugs.php.net/bug.php?id=47494 )
printf ("before getfilecontent\n");
printf ("after getfilecontent\n");
PHP Warning: file_get_contents(no/suchfile): failed to open stream: No such file or directory in /local/home/projects/devel/phptest/loopy.php on line 8
<b>Warning</b>: file_get_contents(no/suchfile): failed to open stream: No such file or directory in <b>/local/home/projects/devel/phptest/loopy.php</b> on line <b>8</b><br />
Add a Patch
Add a Pull Request
I can confirm this issue. It happens for all unsupported "charsets", i.e.
for those that htmlentities() would throw a respective warning. See
> 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
> 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:
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(), 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?
Argh, I'm sorry about this, I probably should have tested that fix more than I did.
I'm looking into this now.
Automatic comment on behalf of firstname.lastname@example.org
Log: Fix bug #75236
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():
var_dump(htmlentities("\x01\x3c", ENT_COMPAT, 'UTF-16BE'));
outputs something like:
Warning: htmlentities(): charset `UTF-16BE' not supported, assuming utf-8
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, but I'm not
sure whether that would be welcome. I suggest to ask on email@example.com
Related To: Bug #75362