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 #37575 [Com]: Faulting application w3wp.exe
Edit report at http://bugs.php.net/bug.php?id=37575&edit=1 ID: 37575 Comment by: coden at fflt dot com Reported by:richardvernooij at yahoo dot com Summary:Faulting application w3wp.exe Status: No Feedback Type: Bug Package:IIS related Operating System: Windows 2003 server PHP Version:5.2 Assigned To:pajoye Block user comment: N Private report: N New Comment: I know you guys hate this, but several years later: "Me too!" Do later PHP versions resolve this issue? Previous Comments: [2009-10-18 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-10-10 13:41:05] paj...@php.net Please use the NTS build of PHP 5.2.11 and try again with FastCGI and not the ISAPI sapi. The ISAPI is deprecated and not maintained anymore, FastCGI is the recommended way to use PHP with IIS (by php.net and MS). [2009-10-10 12:38:02] nishant dot nigam at hkdigitalonline dot com Hii, I am also facing the same annoying problem from the past few days I'm using PHP 5.2.5 IIS 6 WIN 2k3 and Sql Server as backend Andd while performinng some databbase task i get "PHP has encountered an access violation at " After restarting the IIS it gets away for some time and then it returns. Willl Apache solve my problem or is this cozz i'm using some sql server cconnection exteensions in my application. Any help will be appreciated.. [2008-10-31 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-10-23 15:52:42] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. I would also suggest to use FastCGI instead (fcgi is available for IIS 6 and 7). 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 http://bugs.php.net/bug.php?id=37575 -- Edit this bug report at http://bugs.php.net/bug.php?id=37575&edit=1
Bug #47494 [Bgs]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Updated by: ras...@php.net
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 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.
Previous Comments:
[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 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
Bug #54626 [Opn->Bgs]: Access to undeclared static property - But it exists
Edit report at http://bugs.php.net/bug.php?id=54626&edit=1
ID: 54626
Updated by: cataphr...@php.net
Reported by:kjakobi at goodgamestudios dot com
Summary:Access to undeclared static property - But it exists
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: Debian
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Closing as bogus.
Previous Comments:
[2011-05-01 01:07:23] lrtherond at gmail dot com
I take back my report. It was user error in my case. Code on the server
was not in
synch with local repository.
My bad, sorry.
[2011-05-01 00:26:01] lrtherond at gmail dot com
I see this as well, for me it happens all the time...
I have this code:
---
namespace SquadMixer;
use Glint\CommonMagic\DataFormatter as DataFormatter;
use Glint\CommonMagic\Debugging as Debugging;
use Glint\CommonMagic\GlintException as GlintException;
//{{{ Registrar
class Registrar extends ModelEntity {
private static $REGISTRATION= 0;
private static $UPDATE = 1;
private static $PASSWORD_REQUEST= 2;
...
---
self::$REGISTRATION and self::$UPDATE always work.
self::$PASSWORD_REQUEST always fail with:
PHP Fatal error: Access to undeclared static property:
SquadMixer\\Registrar::$PASSWORD_REQUEST
Strangest thing ever...
[2011-04-28 23:12:44] kjakobi at goodgamestudios dot com
Just found out it happens only when using namespaces. Without the
namespace I didn't get the error. Also I can say the error occurs ones
on ~1000 calls on the file. Really strange.
[2011-04-28 21:31:40] kjakobi at goodgamestudios dot com
Yes, tomorrow. But the same code ran fine on 5.3.5 on the same machine.
[2011-04-28 21:23:57] ras...@php.net
Could you check if you can reproduce the problem with suhosin disabled?
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
http://bugs.php.net/bug.php?id=54626
--
Edit this bug report at http://bugs.php.net/bug.php?id=54626&edit=1
Bug #51472 [Com]: DateTime::createFromFormat() does not accept 'W' or 'w' format specifier
Edit report at http://bugs.php.net/bug.php?id=51472&edit=1
ID: 51472
Comment by: sjaillet at gmail dot com
Reported by:wmbr at cust dot in
Summary:DateTime::createFromFormat() does not accept 'W' or
'w' format specifier
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: ubuntu
PHP Version:5.3.2
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This missing feature (of w at least) requires parsing the english
textual representation of days for localizing it. Obtaining an index
would be much more efficient !
Previous Comments:
[2010-04-04 18:30:55] wmbr at cust dot in
Description:
Although the documentation claims every "Format accepted by date()" is
accepted by DateTime::createFromFormat()
(http://www.php.net/manual/en/datetime.createfromformat.php), the
specifiers 'W' and 'w' are actually not.
So this is either a bug or a documentation-error.
Test script:
---
$mydate = DateTime::createFromFormat('W', '1');
print_r(DateTime::getLastErrors());
--
Edit this bug report at http://bugs.php.net/bug.php?id=51472&edit=1
Bug #54644 [Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644&edit=1 ID: 54644 Updated by: and...@php.net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: Tony, you are not exactly right. ext/mysql/mysql_mysqlnd.h is not a left-over. If you take a look into ext/mysqli you will find mysqli_mysqlnd.h, which is larger but follows the same schema - ext_driver (mysqli_libmysql.h exists). However, mysql_myslqnd.h is so small, that it could be incorporated into another file, if wanted. Best, Andrey Previous Comments: [2011-05-03 06:56:38] tony2...@php.net I didn't commit the patch yet, I still want to hear from the MySQL guys first. Also it's their domain, not mine. [2011-05-02 22:32:28] public at grik dot net thanks! I am sorry for the wrong initial description, complaining at # include "ext/mysqlnd/mysqlnd.h" while the error clearly told about "ext/mysql/mysql_mysqlnd.h" [2011-05-02 21:20:36] tony2...@php.net There's also another issue: you can't install mysqlnd itself, you have to install one of the extensions using it. So in order to build shared version of PDO_MYSQL with myslnd you have to build ext/mysql with myslnd *statically*. I believe ext/mysqlND should be full-grown extension with its own --enable-mysqlnd option, this was you could build it separately AND still be able to use your automagic with $PHP_MYSQLND_ENABLED. [2011-05-02 21:12:41] tony2...@php.net The problem is quite weird. I guess this line: # include "ext/mysql/mysql_mysqlnd.h" ..is some kind of leftover from the good ol' times when mysqlnd was a part of ext/mysql/; at least nothing breaks if I remove it. So the patch is as easy as this: --- php_pdo_mysql_int.h (revision 307861) +++ php_pdo_mysql_int.h (working copy) @@ -25,7 +25,6 @@ #if defined(PDO_USE_MYSQLND) # include "ext/mysqlnd/mysqlnd.h" -# include "ext/mysql/mysql_mysqlnd.h" # include "ext/mysqlnd/mysqlnd_libmysql_compat.h" # define PDO_MYSQL_PARAM_BIND MYSQLND_PARAM_BIND #else [2011-05-02 20:19:11] public at grik dot net There is one phpize in the system, and I reinstalled PHP to ensure the error persists. mysqlnd.h exists and is present in the proper folder [root@devel php-5.3.6]# whereis phpize phpize: /usr/local/bin/phpize [root@devel php-5.3.6]# phpize -v Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 [root@devel php-5.3.6]# locate mysqlnd.h /usr/local/include/php/ext/mysqlnd/mysqlnd.h /usr/local/include/php/ext/mysqlnd/php_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysql/mysql_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqli/mysqli_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/php_mysqlnd.h [root@devel php-5.3.6]# ll /usr/local/include/php/ext/mysqlnd/mysqlnd.h -rw-r--r-- 1 root root 17088 2011-05-02 20:49 /usr/local/include/php/ext/mysqlnd/mysqlnd.h [root@devel php-5.3.6]# php-config --includes -I/usr/local/include/php -I/usr/local/include/php/main - I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend - I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib 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 http://bugs.php.net/bug.php?id=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644&edit=1
