Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at https://bugs.php.net/bug.php?id=47494&edit=1 ID: 47494 Comment by: chris at cbsinteractive dot com Reported by:philipp dot feigl at gmail dot com Summary:htmlspecialchars does not throw E_WARNING on multibyte problems Status: Not a bug Type: Bug Package:Strings related Operating System: CentOS5 PHP Version:5.2.8 Block user comment: N Private report: N New Comment: Happening our production servers, can replicate, PHP 5.3.10, Centos 5.6 Previous Comments: [2011-09-27 22:43:02] rudd-o at rudd-o dot com Reported to /r/lolphp here: http://www.reddit.com/r/lolphp/comments/kso6p/if_error_reporting_is_on_htmlspecia lchars_will/ Do you guys realize there is an ENTIRE COMMUNITY of people devoted to the collective practice of FACEPALMING at PHP's fails? Hahaha. [2011-06-01 18:36:28] larry at garfieldtech dot com This bug should be reopened, not just documented. Haven't we learned our lesson with magic_quotes and its ilk? Designing PHP to try and save the user when the user does something stupid always backfires. Always. MySQL has the same problem, and it backfires there, too. The current logic is simply backward. "When display_errors is on, you get all errors except from this function. When display_errors is off, you get no errors except from this one function." There is no logical reason for that. I'm working on a project that has been stalled for over a week while we try to figure out what's wrong with the character encoding configuration on our production server, only to realize that the data is (probably) bad but we didn't know it because of this bug. This is a bug and should be fixed, not simply documented as dumb. If a production server is misconfigured, that's not the job of the language to fix. All that does is, as another commenter noted, punish those who configure their servers properly. If anything, it is a security hole for people who DO configure their server properly by turning off display_errors, as then these strings would get echoed in production. How is that helpful to anyone? [2011-05-03 17:48:02] pinkgothic at gmail dot com Could this bug please get REOPENED as a documentation bug then? As already stated, the absence of the information in the documentation can be crippling for people who do things -right-. (Admittedly right now "htmlspecialchars" has my comment on the subject, but that's hardly official...) (Sidenote: You might also want to close Bug #54109 as bogus for consistency.) [2011-05-03 17:33:35] ras...@php.net This isn't a logic error. The idea is to prevent a user-triggered information leak by not showing this error to the user in case a production server is misconfigured and running with display_errors turned on. [2011-05-02 14:48:50] example at example dot com Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! 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=47494 -- Edit this bug report at https://bugs.php.net/bug.php?id=47494&edit=1
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at https://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: rudd-o at rudd-o dot com
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
Reported to /r/lolphp here:
http://www.reddit.com/r/lolphp/comments/kso6p/if_error_reporting_is_on_htmlspecia
lchars_will/
Do you guys realize there is an ENTIRE COMMUNITY of people devoted to the
collective practice of FACEPALMING at PHP's fails?
Hahaha.
Previous Comments:
[2011-06-01 18:36:28] larry at garfieldtech dot com
This bug should be reopened, not just documented. Haven't we learned our
lesson with magic_quotes and its ilk? Designing PHP to try and save the user
when the user does something stupid always backfires. Always. MySQL has the
same problem, and it backfires there, too.
The current logic is simply backward. "When display_errors is on, you get all
errors except from this function. When display_errors is off, you get no
errors except from this one function." There is no logical reason for that.
I'm working on a project that has been stalled for over a week while we try to
figure out what's wrong with the character encoding configuration on our
production server, only to realize that the data is (probably) bad but we
didn't know it because of this bug.
This is a bug and should be fixed, not simply documented as dumb.
If a production server is misconfigured, that's not the job of the language to
fix. All that does is, as another commenter noted, punish those who configure
their servers properly. If anything, it is a security hole for people who DO
configure their server properly by turning off display_errors, as then these
strings would get echoed in production. How is that helpful to anyone?
[2011-05-03 17:48:02] pinkgothic at gmail dot com
Could this bug please get REOPENED as a documentation bug
then? As already stated, the absence of the information in
the documentation can be crippling for people who do things
-right-. (Admittedly right now "htmlspecialchars" has my
comment on the subject, but that's hardly official...)
(Sidenote: You might also want to close Bug #54109 as bogus
for consistency.)
[2011-05-03 17:33:35] ras...@php.net
This isn't a logic error. The idea is to prevent a user-triggered information
leak by not showing this error to the user in case a production server is
misconfigured and running with display_errors turned on.
[2011-05-02 14:48:50] example at example dot com
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too!
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid multibyte sequence
in argument");
}
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=47494
--
Edit this bug report at https://bugs.php.net/bug.php?id=47494&edit=1
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: larry at garfieldtech dot com
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
This bug should be reopened, not just documented. Haven't we learned
our lesson with magic_quotes and its ilk? Designing PHP to try and save
the user when the user does something stupid always backfires. Always.
MySQL has the same problem, and it backfires there, too.
The current logic is simply backward. "When display_errors is on, you
get all errors except from this function. When display_errors is off,
you get no errors except from this one function." There is no logical
reason for that.
I'm working on a project that has been stalled for over a week while we
try to figure out what's wrong with the character encoding configuration
on our production server, only to realize that the data is (probably)
bad but we didn't know it because of this bug.
This is a bug and should be fixed, not simply documented as dumb.
If a production server is misconfigured, that's not the job of the
language to fix. All that does is, as another commenter noted, punish
those who configure their servers properly. If anything, it is a
security hole for people who DO configure their server properly by
turning off display_errors, as then these strings would get echoed in
production. How is that helpful to anyone?
Previous Comments:
[2011-05-03 17:48:02] pinkgothic at gmail dot com
Could this bug please get REOPENED as a documentation bug
then? As already stated, the absence of the information in
the documentation can be crippling for people who do things
-right-. (Admittedly right now "htmlspecialchars" has my
comment on the subject, but that's hardly official...)
(Sidenote: You might also want to close Bug #54109 as bogus
for consistency.)
[2011-05-03 17:33:35] ras...@php.net
This isn't a logic error. The idea is to prevent a user-triggered
information
leak by not showing this error to the user in case a production server
is
misconfigured and running with display_errors turned on.
[2011-05-02 14:48:50] example at example dot com
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the
same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I
don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid multibyte sequence
in argument");
}
[2011-03-10 17:37:31] pinkgothic at gmail dot com
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 a configuration variable tells that errors are shown on screen then
I
> think all errors (dependent on reporting level) are shown - and not
that
> they can be only logged if the configuration variable is turned off.
> I think/hope this is not only my opinion.
Yeah, you're not alone; but live and learn, I guess? :)
> 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 somethi
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: pinkgothic at gmail dot com
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
Could this bug please get REOPENED as a documentation bug
then? As already stated, the absence of the information in
the documentation can be crippling for people who do things
-right-. (Admittedly right now "htmlspecialchars" has my
comment on the subject, but that's hardly official...)
(Sidenote: You might also want to close Bug #54109 as bogus
for consistency.)
Previous Comments:
[2011-05-03 17:33:35] ras...@php.net
This isn't a logic error. The idea is to prevent a user-triggered
information
leak by not showing this error to the user in case a production server
is
misconfigured and running with display_errors turned on.
[2011-05-02 14:48:50] example at example dot com
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the
same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I
don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid multibyte sequence
in argument");
}
[2011-03-10 17:37:31] pinkgothic at gmail dot com
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 a configuration variable tells that errors are shown on screen then
I
> think all errors (dependent on reporting level) are shown - and not
that
> they can be only logged if the configuration variable is turned off.
> I think/hope this is not only my opinion.
Yeah, you're not alone; but live and learn, I guess? :)
> 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).
Well, from my experience, people who deliberately turn display_errors on
for development except their feedback in
the browser window [*unless* they are writing for XHR], not in a log
they may also be running in parallel.
This is especially true if you have a complex application that logs
debug information from several services into one
file in a compact format - so, unless you're LOOKING for an error, you
won't spot anything. (Total sidenote, I
honestly wish I could change the log format I have to suffer... but I'm
stuck with it. Gargh.)
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.
By the time you find this closed php bug... well, if you're lucky,
you've forced your developers to have a wrapper
function you can now add a try-catch to - otherwise you can now do a
project-wide search for every call of the
function. [To be fair, I was fortunately lucky.]
Could this bug please get REOPENED as a documentation bug? I think
adding this behaviour to the documentation would
help a lot
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: example at example dot com
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Previous Comments:
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the
same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I
don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Invalid multibyte sequence
in argument");
}
[2011-03-10 17:37:31] pinkgothic at gmail dot com
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 a configuration variable tells that errors are shown on screen then
I
> think all errors (dependent on reporting level) are shown - and not
that
> they can be only logged if the configuration variable is turned off.
> I think/hope this is not only my opinion.
Yeah, you're not alone; but live and learn, I guess? :)
> 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).
Well, from my experience, people who deliberately turn display_errors on
for development except their feedback in
the browser window [*unless* they are writing for XHR], not in a log
they may also be running in parallel.
This is especially true if you have a complex application that logs
debug information from several services into one
file in a compact format - so, unless you're LOOKING for an error, you
won't spot anything. (Total sidenote, I
honestly wish I could change the log format I have to suffer... but I'm
stuck with it. Gargh.)
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.
By the time you find this closed php bug... well, if you're lucky,
you've forced your developers to have a wrapper
function you can now add a try-catch to - otherwise you can now do a
project-wide search for every call of the
function. [To be fair, I was fortunately lucky.]
Could this bug please get REOPENED as a documentation bug? I think
adding this behaviour to the documentation would
help a lot of people confused by it.
[2010-06-14 13:30:05] trueleader at gmx dot de
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
We just lost some data, because we fill a JS confirm message on a HTML
click event with a string from a PHP language variable. Nobody knows
that we missed to utf8_encode because all developers use display_errors
on and therefor no error is shown/logged for this problem
---
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1 ID: 47494 Comment by: pinkgothic at gmail dot com Reported by:philipp dot feigl at gmail dot com Summary:htmlspecialchars does not throw E_WARNING on multibyte problems Status: Bogus Type: Bug Package:Strings related Operating System: CentOS5 PHP Version:5.2.8 Block user comment: N Private report: N New Comment: 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 a configuration variable tells that errors are shown on screen then I > think all errors (dependent on reporting level) are shown - and not that > they can be only logged if the configuration variable is turned off. > I think/hope this is not only my opinion. Yeah, you're not alone; but live and learn, I guess? :) > 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). Well, from my experience, people who deliberately turn display_errors on for development except their feedback in the browser window [*unless* they are writing for XHR], not in a log they may also be running in parallel. This is especially true if you have a complex application that logs debug information from several services into one file in a compact format - so, unless you're LOOKING for an error, you won't spot anything. (Total sidenote, I honestly wish I could change the log format I have to suffer... but I'm stuck with it. Gargh.) 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. By the time you find this closed php bug... well, if you're lucky, you've forced your developers to have a wrapper function you can now add a try-catch to - otherwise you can now do a project-wide search for every call of the function. [To be fair, I was fortunately lucky.] Could this bug please get REOPENED as a documentation bug? I think adding this behaviour to the documentation would help a lot of people confused by it. Previous Comments: [2010-06-14 13:30:05] trueleader at gmx dot de Why the developer of the language create a workaround for bad configured servers and/or applications? If a configuration variable tells that errors are shown on screen then I think all errors (dependent on reporting level) are shown - and not that they can be only logged if the configuration variable is turned off. I think/hope this is not only my opinion. We just lost some data, because we fill a JS confirm message on a HTML click event with a string from a PHP language variable. Nobody knows that we missed to utf8_encode because all developers use display_errors on and therefor no error is shown/logged for this problem [2009-11-20 20:24:21] s...@php.net 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). [2009-02-25 13:48:11] j...@php.net It's intentional. If you disagree, please ask s...@php.net why it is like this (I once reverted that :) [2009-02-24 13:57:32] philipp dot feigl at gmail dot com Description: When using htmlspecialchars with a invalid multibyte string and
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: trueleader at gmx dot de
Reported by: philipp dot feigl at gmail dot com
Summary: htmlspecialchars does not throw E_WARNING on multibyte
problems
Status: Bogus
Type: Bug
Package: Strings related
Operating System: CentOS5
PHP Version: 5.2.8
New Comment:
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
We just lost some data, because we fill a JS confirm message on a HTML
click event with a string from a PHP language variable. Nobody knows
that we missed to utf8_encode because all developers use display_errors
on and therefor no error is shown/logged for this problem
Previous Comments:
[2009-11-20 20:24:21] s...@php.net
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).
[2009-02-25 13:48:11] j...@php.net
It's intentional. If you disagree, please ask s...@php.net why it is
like this (I once reverted that :)
[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/bug.php?id=47494&edit=1
