Bug #54109 [Com]: display_errors setting causes unwanted changes in errors reported

Edit report at http://bugs.php.net/bug.php?id=54109&edit=1 ID: 54109 Comment by: pinkgothic at gmail dot com Reported by: fake at example dot com Summary: display_errors setting causes unwanted changes in errors reported Status: Verified Type: Bug Package: *Configuration Issues Operating System: any PHP Version: trunk-SVN-2011-02-27 (SVN) Block user comment: N Private report: N New Comment: See also Bug #47494. I commented there, but reckon it might be a good idea to comment here, as well, seeing as this bug is still open. :) > I'm afraid this isn't just confusing, but actually punishes people > who do it right by blindsiding them completely. > > Scenario: > > * display_errors off > * an Exception-throwing error handler > > As far as I'm informed, this is good practise. (I acknowledge I may > be misinformed.) > > However, due to this behaviour, you suddenly get application crashes > in production without that anyone really understands why the code > snippet is suddenly a culprit. 'But we tested it with broken UTF-8, > why are -we- just getting empty strings? And the documentation says > that's what we should be expecting...' [...] > If you've been a good developer and read the manual on > htmlspecialchars(), you're not going to expect an error. You're > going to expect an empty string. Unfortunately currently, nothing > in the documentation reveals that the function results in an > E_WARNING, either pure-log-only when display_errors is on, or > log and trigger_error()ed when display_errors is off. I reckon this should at the very least be a documentation error, if this explanation from stas@php.net holds: > The idea is to return an error but not display it (i.e. log it > or allow custom error handlers to process it). > > The reason for it is that, unfortunately, people run servers in > production with display_errors=On, and > php_escape_html_entities_ex can be triggered from all kinds of > code that usually doesn't produce errors, which can reveal > sensitive information on public sites. So we chose to go after > lesser of two evils and not generate the error in this context. > > For debugging, I would suggest always logging errors and > checking the error log, as some errors may be hard to spot in > display anyway (especially true if your script produces > something like JSON). Previous Comments: ------------------------------------------------------------------------ [2011-02-27 03:08:43] fake at example dot com Description: ------------ Following functions may report E_WARNING when invalid utf8 sequence detected. json_encode htmlspecialchars htmlentities However, they only issue the warning if display_errors is OFF. display_errors should not dictate whether the warning is triggered. They behave this way because of following dumb logic in source code if (!PG(display_errors)) { php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid UTF-8 sequence in argument"); } ext/standard/html.c php_escape_html_entities_ex ext/json/json.c json_escape_string This is more or less a repeat of http://bugs.php.net/bug.php?id=52397 which unfortunately got marked bogus. Test script: --------------- ini_set('display_errors', 1); json_encode("\xFF"); var_dump(error_get_last()); echo "-------\n"; ini_set('display_errors', 0); json_encode("\xFF"); var_dump(error_get_last()); //these have same problem //htmlspecialchars("\xFF", ENT_COMPAT, 'utf-8'); //htmlentities("\xFF", ENT_COMPAT, 'utf-8'); Expected result: ---------------- I expect both calls to error_get_last() should not return null. Also, I should have two entries in my error log. Actual result: -------------- First call to error_get_last() returns null, second call works. Only one message in error log. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=54109&edit=1