[PHP-BUG] Bug #53936 [NEW]: Literal empty array returns NULL.
From:
Operating system: Linux
PHP version: 5.3.5
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Literal empty array returns NULL.
Description:
For some reason I cannot figure out, array() doesn't give me an empty array
anymore but NULL.
(References are used for good reasons, btw.)
Test script:
---
function &foo_to_array (&$x)
{
$array_to_return = array (); // Works the first couple of times, then
NULLs.
// add foo elements to array
return $array_to_return;
}
Introducing some wrapper doesn't help either -- an array is actually
created but NULL is returned anyway:
function make_array ()
{
return array ();
}
--
Edit bug report at http://bugs.php.net/bug.php?id=53936&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53936&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53936&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53936&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53936&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53936&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53936&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53936&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53936&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53936&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53936&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53936&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53936&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53936&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53936&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53936&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53936&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53936&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53936&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53936&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53936&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53936&r=mysqlcfg
Bug #53932 [Bgs]: is_callable invoke autoloading unnecessarilly
Edit report at http://bugs.php.net/bug.php?id=53932&edit=1 ID: 53932 User updated by:rubs33 at gmail dot com Reported by:rubs33 at gmail dot com Summary:is_callable invoke autoloading unnecessarilly Status: Bogus Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: ok Previous Comments: [2011-02-05 03:56:46] cataphr...@php.net 1. A fatal error is not a crash. 2. What constitutes an acceptable class name is, in practice, more ample than what's in the manual, though there are no guarantees it will work in the future. 3. You don't have to throw exceptions from __autoload; in fact, if you did, you were unable to catch them prior to 5.3. 4. Validate user input. [2011-02-04 22:44:55] rubs33 at gmail dot com Description: The PHP core function "is_callable" invokes the autoloading when receives a string callback that has "::", even when the class has not a valid name. It could be smarter invoking autoloading only when the class name is a valid class name, as described by the expression [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* from documentation (http://www.php.net/manual/en/language.oop5.basic.php). It should check whether a namespace was used too. Often, is_callable function is not invoked in a try/catch context. So, in many cases, it could crash PHP execution. For example, in a dispatcher implementation that receives a controller class and an action (method) by user, create a callback and test it with is_callable. Test script: --- http://bugs.php.net/bug.php?id=53932&edit=1
Bug #47580 [Opn->Fbk]: MSSQL: "Changed database context to" when connecting
Edit report at http://bugs.php.net/bug.php?id=47580&edit=1
ID: 47580
Updated by: paj...@php.net
Reported by:maxcamo at gmail dot com
Summary:MSSQL: "Changed database context to" when connecting
-Status: Open
+Status: Feedback
Type: Bug
Package:MSSQL related
Operating System: Win2003
PHP Version:5.2CVS-2009-03-05 (snap)
Block user comment: N
Private report: N
New Comment:
If you can try it on linux/unix with 5.3, please try it. If not I would
suggest to
use sqlsrv (http://sqlsrvphp.codeplex.com/) instead on Windows (and php
5.3).
Previous Comments:
[2011-02-05 20:29:14] nkrsaxena at gmail dot com
I am facing this problem, making me nuts :-X
it shows mssql connection connected
mssql selectdb fine
but while running query says "Changed database context to" and script
terminated
the same is working fine
1. On MSSQL ternimal
2. php5.1.6
i tried different RPMS and manual installation with all dependencies but
still
no luck, even on Clean servers RHEL5
Please help...
[2009-06-13 13:16:11] maxcamo at gmail dot com
I've tried but i get the same problem
Can be related to mssql time_wait tcp/ip?
Thx
Massimo
[2009-06-02 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".
[2009-05-25 19:46:59] ka...@php.net
Have you tried to change the severity with mssql_min_message_severity?
Error 5701 (Changed database context to) is at severity 10.
[2009-03-25 16:51:53] maxcamo at gmail dot com
ok but i can't connect to the db,
chaging the script like this
if ($connDb)
mssql_select_db($db, $connDb);
else
$lastmsg=mssql_get_last_message()
and...
fputs($fp, gmdate("M d Y H:i:s") . ":: Try:$tries ::
".$ServerName."::
".$lastmsg." :: ". $pageName . "\r\n");
i dont' get any mssql errors, but i get the same problem
I see this error randomly, or on heavy load, i think
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=47580
--
Edit this bug report at http://bugs.php.net/bug.php?id=47580&edit=1
Bug #47580 [Com]: MSSQL: "Changed database context to" when connecting
Edit report at http://bugs.php.net/bug.php?id=47580&edit=1
ID: 47580
Comment by: nkrsaxena at gmail dot com
Reported by:maxcamo at gmail dot com
Summary:MSSQL: "Changed database context to" when connecting
Status: Open
Type: Bug
Package:MSSQL related
Operating System: Win2003
PHP Version:5.2CVS-2009-03-05 (snap)
Block user comment: N
Private report: N
New Comment:
I am facing this problem, making me nuts :-X
it shows mssql connection connected
mssql selectdb fine
but while running query says "Changed database context to" and script
terminated
the same is working fine
1. On MSSQL ternimal
2. php5.1.6
i tried different RPMS and manual installation with all dependencies but
still
no luck, even on Clean servers RHEL5
Please help...
Previous Comments:
[2009-06-13 13:16:11] maxcamo at gmail dot com
I've tried but i get the same problem
Can be related to mssql time_wait tcp/ip?
Thx
Massimo
[2009-06-02 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".
[2009-05-25 19:46:59] ka...@php.net
Have you tried to change the severity with mssql_min_message_severity?
Error 5701 (Changed database context to) is at severity 10.
[2009-03-25 16:51:53] maxcamo at gmail dot com
ok but i can't connect to the db,
chaging the script like this
if ($connDb)
mssql_select_db($db, $connDb);
else
$lastmsg=mssql_get_last_message()
and...
fputs($fp, gmdate("M d Y H:i:s") . ":: Try:$tries ::
".$ServerName."::
".$lastmsg." :: ". $pageName . "\r\n");
i dont' get any mssql errors, but i get the same problem
I see this error randomly, or on heavy load, i think
[2009-03-09 07:32:52] maxcamo at gmail dot com
ok but i can't connect to the db,
chaging the script like this
if ($connDb)
mssql_select_db($db, $connDb);
else
$lastmsg=mssql_get_last_message()
and...
fputs($fp, gmdate("M d Y H:i:s") . ":: Try:$tries ::
".$ServerName."::
".$lastmsg." :: ". $pageName . "\r\n");
i dont' get any mssql errors, but i get the same problem
I see this error randomly, or on heavy load, i think
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=47580
--
Edit this bug report at http://bugs.php.net/bug.php?id=47580&edit=1
Bug #34784 [Com]: Changed database context error when SELECT > 33 columns
Edit report at http://bugs.php.net/bug.php?id=34784&edit=1
ID: 34784
Comment by: nkrsaxena at gmail dot com
Reported by:jwall at webpeak dot com
Summary:Changed database context error when SELECT > 33
columns
Status: Assigned
Type: Bug
Package:MSSQL related
Operating System: Windows XP
PHP Version:5CVS-2005-10-08 (snap)
Assigned To:fmk
Block user comment: N
Private report: N
New Comment:
This Bug is driving me crazy man, I am using
RHEL 5
Apache 2.0 server handler
Mysql 5.0
And trying to install PHP5.3.5
installed all necessary file, now i use to connect to MSSQL server, my
script
shows
DB connected
DB selected
while performing Query it return "Changed database context XXX"
i have checked the same query on below two and running perfect
1. MSSQL terminal running file
2. Ran same script with all settings except PHP version 4.3.2 and 5.1.6
I tried the with RPM's as well but no luck. Googled a lot but no
solution for
the same.
Previous Comments:
[2009-12-04 20:59:39] chrisgenrich at bmminvestments dot com
I was getting this error with a long running query and modified the
php.ini to the following:
; Minimum error severity to display.
mssql.min_error_severity = 0
; Minimum message severity to display.
mssql.min_message_severity = 17
It's possible that lower settings could work as well...
[2009-03-10 14:00:48] markus_hay at quantumdigital dot com
This bug has not been fixed and it's driving me absolutely nuts as I can
not seem to reproduce it in a non-production environment to find a
workaround. It happens on UPDATEs, INSERTs, SELECTs, etc., and it's
completely random.
I don't know if it's a PHP issue or a PEAR issue, but as of PHP 5.2.5
and PEAR 1.7.2 the so-called informative message of "Changed database
context to ..." is still appearing. OS is Windows Server 2k3 and
database is MS SQL Server 2005.
The following settings are used in php.ini:
===
mssql.min_error_severity = 10
mssql.min_message_severity = 10
Here is some example code:
==
$sSql = 'UPDATE Table SET iNumber = 5 WHERE iRecordId = 666';
if (PEAR::isError($oResults = $rDbConn->query($sSql))) {
die($oResults->getMessage());
}
Typical output would be:
[Native code: 0]
[Native message: Changed database context to 'TableName'.]
Is this ever going to get fixed?
[2008-03-06 18:45:55] arn_schw at yahoo dot com
Hi ,
I've written this code to use the data stored in the data-base named
moviesite. The result is supposed to print the names of three different
movies each one time.But,I get each 51 times I couldn't get where the
error is present.So,please help me in rectifying my mistake..
1900 " .
"ORDER BY movie_name " ;
$res = mysql_query ( $result )
or die ( mysql_error ( ) ) ;
$st = 0 ;
while( $ress = mysql_fetch_assoc ( $res ) )
{
extract ( $ress ) ;
echo "$movie_name" ;
echo "" ;
$st = $st+1 ;
}
echo "Finally the number of times it is printed is".$st ;
?>
[2007-09-05 17:18:22] php at blazemonger dot com
I am seeing this error on *every* MSSQL query under PHP 5.2.2, on
Windows 2003 Server x64, in the apache 2.2.4 error log file.
[2007-07-03 23:39:38] vollmer at ampache dot org
I'm running into this same issue with large result sets.
I am running a Debian ETCH server with Apache2/PHP5.2
dpkg --list | grep "php"
ii libapache2-mod-php5 5.2.0-8+etch4
server-side, HTML-embedded scripting languag
ii php-pear 5.2.0-8+etch4
PEAR - PHP Extension and Application Reposit
ii php5-cli 5.2.0-8+etch4
command-line interpreter for the php5 script
ii php5-common 5.2.0-8+etch4
Common files for packages built from the php
ii php5-curl 5.2.0-8+etch4
CURL module for php5
ii php5-gd 5.2.0-8+etch4 GD
module for php5
ii php5-ldap 5.2.0-8+etch4
LDAP module for php5
ii php5-mcrypt 5.2.0-8+etch4
MCrypt module for php5
ii php5-mysql5.2.0-8+etch4
MySQL module for php5
ii php5-snmp 5.2.0-8+etch4
SNMP m
Bug #53934 [Ver]: The negative PHP_INT_MAX is incorrectly converted to float
Edit report at http://bugs.php.net/bug.php?id=53934&edit=1 ID: 53934 Updated by: cataphr...@php.net Reported by:eriksen dot costa at infranology dot com dot br Summary:The negative PHP_INT_MAX is incorrectly converted to float Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: The problem is that "-9223372036854775808" is not parsed as an integer, instead the minus sign and the rest are parsed individually and 9223372036854775808 is bigger than LONG_MAX. Probably this is not trivial to fix. Previous Comments: [2011-02-05 14:53:32] eriksen dot costa at infranology dot com dot br Description: I found this and seems a bug. Everytime I use the negative PHP_INT_MAX literally (-9223372036854775808) as a function parameter, it is converted to float. However, if I pass it like an expression -9223372036854775807 - 1, it is correctly identified as an integer. Test script: --- --TEST-- Checks if the negative PHP_INT_MAX is treated as integer. --CREDITS-- Eriksen Costa --SKIPIF-- --FILE-- --EXPECT-- int(-9223372036854775808); int(-9223372036854775808); int(-9223372036854775808); Expected result: int(-9223372036854775808); int(-9223372036854775808); int(-9223372036854775808); Actual result: -- int(-9223372036854775808) int(-9223372036854775808) float(-9.2233720368548E+18) -- Edit this bug report at http://bugs.php.net/bug.php?id=53934&edit=1
Bug #53934 [Opn->Ver]: The negative PHP_INT_MAX is incorrectly converted to float
Edit report at http://bugs.php.net/bug.php?id=53934&edit=1 ID: 53934 Updated by: cataphr...@php.net Reported by:eriksen dot costa at infranology dot com dot br Summary:The negative PHP_INT_MAX is incorrectly converted to float -Status: Open +Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N Previous Comments: [2011-02-05 14:53:32] eriksen dot costa at infranology dot com dot br Description: I found this and seems a bug. Everytime I use the negative PHP_INT_MAX literally (-9223372036854775808) as a function parameter, it is converted to float. However, if I pass it like an expression -9223372036854775807 - 1, it is correctly identified as an integer. Test script: --- --TEST-- Checks if the negative PHP_INT_MAX is treated as integer. --CREDITS-- Eriksen Costa --SKIPIF-- --FILE-- --EXPECT-- int(-9223372036854775808); int(-9223372036854775808); int(-9223372036854775808); Expected result: int(-9223372036854775808); int(-9223372036854775808); int(-9223372036854775808); Actual result: -- int(-9223372036854775808) int(-9223372036854775808) float(-9.2233720368548E+18) -- Edit this bug report at http://bugs.php.net/bug.php?id=53934&edit=1
[PHP-BUG] Bug #53934 [NEW]: The negative PHP_INT_MAX is incorrectly converted to float
From: Operating system: Linux PHP version: 5.3.5 Package: Scripting Engine problem Bug Type: Bug Bug description:The negative PHP_INT_MAX is incorrectly converted to float Description: I found this and seems a bug. Everytime I use the negative PHP_INT_MAX literally (-9223372036854775808) as a function parameter, it is converted to float. However, if I pass it like an expression -9223372036854775807 - 1, it is correctly identified as an integer. Test script: --- --TEST-- Checks if the negative PHP_INT_MAX is treated as integer. --CREDITS-- Eriksen Costa --SKIPIF-- --FILE-- --EXPECT-- int(-9223372036854775808); int(-9223372036854775808); int(-9223372036854775808); Expected result: int(-9223372036854775808); int(-9223372036854775808); int(-9223372036854775808); Actual result: -- int(-9223372036854775808) int(-9223372036854775808) float(-9.2233720368548E+18) -- Edit bug report at http://bugs.php.net/bug.php?id=53934&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53934&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53934&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53934&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53934&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53934&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53934&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53934&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53934&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53934&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53934&r=support Expected behavior: http://bugs.php.net/fix.php?id=53934&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53934&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53934&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53934&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53934&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53934&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53934&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53934&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53934&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53934&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53934&r=mysqlcfg
Bug #53805 [Opn->Tbd]: filter_input_array ommits SERVER['REQUEST_TIME'] input
Edit report at http://bugs.php.net/bug.php?id=53805&edit=1 ID: 53805 Updated by: ka...@php.net Reported by:it at x-trader dot cz Summary:filter_input_array ommits SERVER['REQUEST_TIME'] input -Status: Open +Status: To be documented Type: Bug Package:Filter related Operating System: linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: . Previous Comments: [2011-01-21 21:23:19] it at x-trader dot cz Thank you for your prompt response. >From the user doesn't come many other SERVER variables, for example: REDIRECT_STATUS, PATH, DOCUMENT_ROOT, SCRIPT_FILENAME, GATEWAY_INTERFACE, SERVER_PROTOCOL, REQUEST_METHOD, SCRIPT_NAME, PHP_SELF etc. Should be at least documented. [2011-01-21 20:34:39] ras...@php.net REQUEST_TIME doesn't come from the user. It is added to the $_SERVER array after input filtering runs. [2011-01-21 20:30:53] it at x-trader dot cz Description: Function filter_input_array does NOT return from SERVER input variable REQUEST_TIME key => value pair. Tested on Linux, PHP versions 5.2.8 and 5.3.2. May be it's undocumented feature or filter implementation failure, because filter functions are using only the original variable values passed to PHP. Test script: --- int(1295636581) } -- Edit this bug report at http://bugs.php.net/bug.php?id=53805&edit=1
Req #53895 [Com]: debug_zval_dump should be by ref
Edit report at http://bugs.php.net/bug.php?id=53895&edit=1 ID: 53895 Comment by: + at ni-po dot com Reported by:+ at ni-po dot com Summary:debug_zval_dump should be by ref Status: Wont fix Type: Feature/Change Request Package:Variables related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Hm, the problem seems to be more complicated when I thought. The only thing I can think of, that would allow arrays and objects, too, is to provide a function zval_is_ref that checks, whether the zval is_ref and then provide two function, zval_dump_by_ref and zval_dump_by_val. Imho this would cover all cases, but I assume that that's too many functions. Previous Comments: [2011-02-04 22:15:29] johan...@php.net The string version won't help for all cases, as you can't adress array elements or objects properly then. So there's no good way. [2011-02-01 15:13:07] + at ni-po dot com That would obviously be even better. I just wanted to note, that something must be changed about it. [2011-02-01 13:49:28] cataphr...@php.net I disagree. Receiving the variable by reference would solve nothing, as it would force a separation on zvals with refcount > 1. What actually ought to be done is make debug_zval_dump work like xdebug's version and accepting a string. [2011-01-31 23:43:14] + at ni-po dot com Description: debug_zval_dump should accept the variable by reference. Currently one can call the function either via debug_zval_dump($var) or debug_zval_dump(&$var). As the latter is as deprecated as it gets (i.e. parse-time deprecated) and is even removed in trunk, the function should be defined as accepting the variable by reference, because this is the usual use case. -- Edit this bug report at http://bugs.php.net/bug.php?id=53895&edit=1
Bug #53795 [Com]: Connect Error from MySqli (mysqlnd) when using SSL
Edit report at http://bugs.php.net/bug.php?id=53795&edit=1
ID: 53795
Comment by: dave dot kelly at dawkco dot com
Reported by:dave dot kelly at dawkco dot com
Summary:Connect Error from MySqli (mysqlnd) when using SSL
Status: Closed
Type: Bug
Package:MySQLi related
Operating System: Windows
PHP Version:5.3.5
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
OK, the patch works. Mysqli (mysqlnd build) on Windows can now use
SSL/TLS connections. Thank you!
Previous Comments:
[2011-01-31 13:51:40] ka...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2011-01-31 13:47:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307880
Log: Fixed bug #53795 (Connect Error from MySqli (mysqlnd) when using
SSL)
[2011-01-30 11:35:52] ka...@php.net
I got an idea why this fails, as MYSQLND_SSL_SUPPORTED is not defined on
Windows, its a simple one line fix that I will commit shortly
[2011-01-29 09:36:07] dave dot kelly at dawkco dot com
FYI (you probably already know): there are currently no SSL/TLS options
available to be set with the mysqli::options method.
I tried using the mysqli::ssl_set method as follows, but it didn't work
either (same connect error):
$mysqli->ssl_set(NULL, // key file path or NULL
NULL, // cert file path or NULL
'C:/ssl/ca-cert.pem', // ca cert file path or NULL
NULL, // capath directory or NULL
'DHE-RSA-AES256-SHA'); // cipher or NULL
Also, tried the following (no luck):
$mysqli->ssl_set('C:/ssl/key.pem', // key file path or NULL
'C:/ssl/cert.pem', // cert file path or NULL
'C:/ssl/ca-cert.pem', // ca cert file path or NULL
NULL, // capath directory or NULL
NULL); // cipher or NULL
As noted before, these all work with PHP 5.2.17, but not with PHP
5.3.5.
A fix for mysqlnd would be great because trying to do a custom build on
Windows with mysqlnd disabled has become a real ordeal.
[2011-01-24 11:12:59] and...@php.net
No, mysqlnd doesn't use my.ini/my.cnf files, as libmysql did. You have
to set your options manually.
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=53795
--
Edit this bug report at http://bugs.php.net/bug.php?id=53795&edit=1
