[PHP-BUG] Bug #60923 [NEW]: Failing tests for sapi/cli

2012-01-29 Thread robertbasic dot com at gmail dot com
From: 
Operating system: GNU/Linux (Fedora 16)
PHP version:  5.4SVN-2012-01-29 (SVN)
Package:  CGI/CLI related
Bug Type: Bug
Bug description:Failing tests for sapi/cli

Description:

After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test

some tests for sapi/cli are failing. These tests were OK when I tested from
tags/php_5_4_0RC6

The failing tests are:

=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=

Full reports were submitted to http://qa.php.net/reports/ after running the
tests.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60923&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60923&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60923&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60923&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60923&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60923&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60923&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60923&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60923&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60923&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60923&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60923&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60923&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60923&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60923&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60923&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60923&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60923&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60923&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60923&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60923&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60923&r=mysqlcfg



Bug #60923 [Com]: Failing tests for sapi/cli

2012-01-29 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1

 ID: 60923
 Comment by: robertbasic dot com at gmail dot com
 Reported by:robertbasic dot com at gmail dot com
 Summary:Failing tests for sapi/cli
 Status: Feedback
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   GNU/Linux (Fedora 16)
 PHP Version:5.4SVN-2012-01-29 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Will do.

By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, 
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the 
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump 
the result from php -n -v.

Actually, all these failing tests are this kind of thing: printing the result, 
var_dumping NULL, instead of var_dumping the result. What's strange, is that, 
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one 
does this (the 2nd), the other 2 work as expected.

Given that this works for RC6, I'm looking at commits since then, to see if 
anything from there is causing this.

Any hints on what should I do to check is my system affecting this somehow? I'm 
using the test instructions you posted on codepad some time ago.

Thanks!


Previous Comments:

[2012-01-29 13:50:42] ras...@php.net

I am not seeing these failures here. Could you dig into one of them to see if 
you 
can figure out why it is failing for you?


[2012-01-29 12:20:21] robertbasic dot com at gmail dot com

Description:

After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test

some tests for sapi/cli are failing. These tests were OK when I tested from 
tags/php_5_4_0RC6

The failing tests are:

=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=

Full reports were submitted to http://qa.php.net/reports/ after running the 
tests.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1


Bug #60923 [Com]: Failing tests for sapi/cli

2012-01-29 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1

 ID: 60923
 Comment by: robertbasic dot com at gmail dot com
 Reported by:robertbasic dot com at gmail dot com
 Summary:Failing tests for sapi/cli
 Status: Feedback
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   GNU/Linux (Fedora 16)
 PHP Version:5.4SVN-2012-01-29 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Hello again!

I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through 
those commits.

What I've managed to do so far is to find what commit is causing the tests to 
fail (at least I think it's this one): 
http://svn.php.net/viewvc?view=revision&revision=322743

The r322743 of the code has the tests failing, while the one prior to it 
(r322678) has the tests passing.

Sadly my C skills are almost non-existent, so I can't promise a patch, but will 
continue to poke around it.


Previous Comments:

[2012-01-29 14:24:04] robertbasic dot com at gmail dot com

Will do.

By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, 
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the 
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump 
the result from php -n -v.

Actually, all these failing tests are this kind of thing: printing the result, 
var_dumping NULL, instead of var_dumping the result. What's strange, is that, 
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one 
does this (the 2nd), the other 2 work as expected.

Given that this works for RC6, I'm looking at commits since then, to see if 
anything from there is causing this.

Any hints on what should I do to check is my system affecting this somehow? I'm 
using the test instructions you posted on codepad some time ago.

Thanks!


[2012-01-29 13:50:42] ras...@php.net

I am not seeing these failures here. Could you dig into one of them to see if 
you 
can figure out why it is failing for you?

--------
[2012-01-29 12:20:21] robertbasic dot com at gmail dot com

Description:

After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test

some tests for sapi/cli are failing. These tests were OK when I tested from 
tags/php_5_4_0RC6

The failing tests are:

=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=

Full reports were submitted to http://qa.php.net/reports/ after running the 
tests.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1


Bug #60923 [Com]: Failing tests for sapi/cli

2012-01-29 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1

 ID: 60923
 Comment by: robertbasic dot com at gmail dot com
 Reported by:robertbasic dot com at gmail dot com
 Summary:Failing tests for sapi/cli
 Status: Feedback
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   GNU/Linux (Fedora 16)
 PHP Version:5.4SVN-2012-01-29 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Think I narrowed it down even more. Seems to me the problem is in the new 
php_output_stderr function - when I comment it out, the tests pass again. I'll 
attach a diff to show what I did.


Previous Comments:

[2012-01-29 16:21:26] robertbasic dot com at gmail dot com

Hello again!

I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through 
those commits.

What I've managed to do so far is to find what commit is causing the tests to 
fail (at least I think it's this one): 
http://svn.php.net/viewvc?view=revision&revision=322743

The r322743 of the code has the tests failing, while the one prior to it 
(r322678) has the tests passing.

Sadly my C skills are almost non-existent, so I can't promise a patch, but will 
continue to poke around it.

----
[2012-01-29 14:24:04] robertbasic dot com at gmail dot com

Will do.

By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, 
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the 
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump 
the result from php -n -v.

Actually, all these failing tests are this kind of thing: printing the result, 
var_dumping NULL, instead of var_dumping the result. What's strange, is that, 
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one 
does this (the 2nd), the other 2 work as expected.

Given that this works for RC6, I'm looking at commits since then, to see if 
anything from there is causing this.

Any hints on what should I do to check is my system affecting this somehow? I'm 
using the test instructions you posted on codepad some time ago.

Thanks!


[2012-01-29 13:50:42] ras...@php.net

I am not seeing these failures here. Could you dig into one of them to see if 
you 
can figure out why it is failing for you?

------------
[2012-01-29 12:20:21] robertbasic dot com at gmail dot com

Description:

After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test

some tests for sapi/cli are failing. These tests were OK when I tested from 
tags/php_5_4_0RC6

The failing tests are:

=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=

Full reports were submitted to http://qa.php.net/reports/ after running the 
tests.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1


Bug #60923 [Com]: Failing tests for sapi/cli

2012-01-30 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1

 ID: 60923
 Comment by: robertbasic dot com at gmail dot com
 Reported by:robertbasic dot com at gmail dot com
 Summary:Failing tests for sapi/cli
 Status: Closed
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   GNU/Linux (Fedora 16)
 PHP Version:5.4SVN-2012-01-29 (SVN)
 Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

Just tested again with this fix/commit, the tests pass again!

Thanks!


Previous Comments:

[2012-01-30 12:20:05] m...@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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




[2012-01-30 12:17:49] m...@php.net

Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revision&revision=322931
Log: use stderr before, stdout after php_output_startup() and 
sapi_module.ub_write() after php_output_activate()

- fixes Bug #60920  CLI: php -v on STDERR
- fixes Bug #60923  Failing tests for sapi/cli


[2012-01-29 19:05:18] ras...@php.net

Yeah, looks to be the same as bug #60920


[2012-01-29 17:39:06] robertbasic dot com at gmail dot com

Think I narrowed it down even more. Seems to me the problem is in the new 
php_output_stderr function - when I comment it out, the tests pass again. I'll 
attach a diff to show what I did.


[2012-01-29 16:21:26] robertbasic dot com at gmail dot com

Hello again!

I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through 
those commits.

What I've managed to do so far is to find what commit is causing the tests to 
fail (at least I think it's this one): 
http://svn.php.net/viewvc?view=revision&revision=322743

The r322743 of the code has the tests failing, while the one prior to it 
(r322678) has the tests passing.

Sadly my C skills are almost non-existent, so I can't promise a patch, but will 
continue to poke around it.




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=60923


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1


Bug #53929 [Com]: no-temporary name for a uploaded file

2012-02-24 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=53929&edit=1

 ID: 53929
 Comment by: robertbasic dot com at gmail dot com
 Reported by:dungar at kabia dot fr
 Summary:no-temporary name for a uploaded file
 Status: Not a bug
 Type:   Bug
 Package:Filesystem function related
 Operating System:   debian
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

This is not a PHP bug, but improper usage of the Zend_File_Transfer component 
from Zend Framework.

In the manual, 
http://framework.zend.com/manual/en/zend.file.transfer.introduction.html#zend.file.transfer.introduction.informations
 there's a clear big warning stating that "due to security reasons also the 
original data within $_FILES will be overridden as soon as Zend_File_Transfer 
is initiated."


Previous Comments:

[2012-02-24 19:37:55] s...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Please review the user comments and reopen if you still consider this a problem.


[2011-07-31 19:55:13] mf_peppa at yahoo dot com

oops, my bad - there is no problem with PHP, it's just a programming error - 
the 
guy who submitted this bug calls $fFile = $oForms_File->getValue('file'), which 
includes a move_uploaded_file() call... that's why the test results are 
wrong... i 
would recommend closing this bug


[2011-07-31 18:53:09] mf_peppa at yahoo dot com

same problem (mac os lion, php 5.3.6)


[2011-02-04 19:25:09] dungar at kabia dot fr

Description:

The function :is_uploaded_file return every time false.
(for a classical upload)
For find the file i must edit the path :
$file['file']['tmp_name']
by this path :
dirname($file['file']['tmp_name']).'/'.$file['file']['name']

The file of the tmp_name wasn't changed, and the uploaded name is used.
(May be dangerous for include attack ?)

Test script:
---
$oForms_File = new Forms_File();
if ( $oForms_File->isValid($_POST) ) {
$fFile = $oForms_File->getValue('file');
$adapter = new Zend_File_Transfer_Adapter_Http();

$adapter->setDestination(CORE_APP_DIR.DS.'modules'.DS.'bugtracking'.DS.'files','test.todel');
; 
$file = $adapter->getFileInfo('file');
echo 
file_get_contents(dirname($file['file']['tmp_name']).'/'.$file['file']['name']);exit;
test($file);
test($_FILES);
test( is_uploaded_file($_FILES['file']['tmp_name']) );
test($adapter->receive());
test($adapter->getMessages());
function ScanDirectory($Directory){

  $MyDirectory = opendir($Directory) or die('Erreur');
while($Entry = @readdir($MyDirectory)) {
if(is_dir($Directory.'/'.$Entry)&& $Entry != '.' && $Entry != 
'..') {
 echo ''.$Directory;
ScanDirectory($Directory.'/'.$Entry);
echo '';
}
else {
echo ''.$Entry.'';
}
}
  closedir($MyDirectory);
}

ScanDirectory('/webdata/n/q/7a8fwoym65pts9/vbi3und15xa44wgw/php_upload');





setName('file');
 /*
 $this->setAction($this->view->url(
array(
'module'=> 
Zend_Controller_Front::getInstance()->getRequest()->getParam('module'),
'controller'=> 'files',
'action'=> 'upload',
'id'=> 
Zend_Controller_Front::getInstance()->getRequest()->getParam('id'),
), $this->routes['crud-action-controller-id'], 
true)
);
   

Bug #54155 [Com]: Insufficient+Inconsistent error reporting

2012-02-24 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=54155&edit=1

 ID: 54155
 Comment by: robertbasic dot com at gmail dot com
 Reported by:a1283465 at jnxjn dot com
 Summary:Insufficient+Inconsistent error reporting
 Status: Open
 Type:   Bug
 Package:Variables related
 Operating System:   Linux
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

I'd argue that one should check that a variable is of an expected type, or 
maybe cast the type to the expected one, before using it.

I vote for "Not a bug".


Previous Comments:

[2011-03-03 23:23:32] a1283465 at jnxjn dot com

Description:

If you try to access an undefined index on an array, you will get an error. But 
if you try the same on bool(false) PHP will silently accept it and ignores the 
error.

Please note that this is especially dangerous on database results, where you 
get false instead of an array when there is no result.

If you try the same on a valid array with an invalid index you will get a 
E_NOTICE.

So trying to use the array operator on a non-array should at least raise an 
E_STRICT error, indicating that there is a problem, instead of silently 
continuing to use the wrong result for further calculations.

Test script:
---
$array1 = false;
$array2 = array('a'=>3);

echo 5+3*$array1['a']; // output: 5

var_dump($array1['b']); // output: NULL
var_dump($array2['b']); // output: Notice:  Undefined index: b







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54155&edit=1


Bug #53823 [Com]: preg_replace: * qualifier on unicode replace garbles the string

2012-02-24 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=53823&edit=1

 ID: 53823
 Comment by: robertbasic dot com at gmail dot com
 Reported by:keith at chaos-realm dot net
 Summary:preg_replace: * qualifier on unicode replace garbles
 the string
 Status: Verified
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.3SVN-2011-01-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

I tried my best on this one. Tested against the trunk:
svn info | grep Revision
Revision: 323476

I created a test file for this, will attach.

I ran the following with gdb:

$ gdb sapi/cgi/php-cgi

and then set a breakpoint

(gdb) break php_pcre.c:1318

finally ran the test script like:

(gdb) run run-tests.php ext/pcre/tests/bug53823.phpt

On https://gist.github.com/1904467 I c/p-ed some output from gdb, but that 
might be incorrect as I'm fairly new to all this. Anyway, lines 12 and 22 in 
that gist caught my attention.

Also, I think the same issue exists for preg_filter, too.


Previous Comments:

[2011-01-26 08:02:54] ahar...@php.net

Verified on 5.3 and trunk.


[2011-01-23 18:10:44] tino dot didriksen at gmail dot com

...and then I forget to change the *. Let's try that again...

These work as expected:
echo preg_replace('/[^\pL\pM]+/iu', '', 'áéíóú');
echo preg_replace('/[^\pL\pM\pN]+/iu', '', 'áéíóú');


[2011-01-23 18:09:23] tino dot didriksen at gmail dot com

A workaround is to use + instead of *.

These work as expected:
echo preg_replace('/[^\pL\pM]*/iu', '', 'áéíóú');
echo preg_replace('/[^\pL\pM\pN]*/iu', '', 'áéíóú');


[2011-01-23 18:04:49] keith at chaos-realm dot net

.


[2011-01-23 18:00:57] keith at chaos-realm dot net

Description:

When using the following test script to strip out all unicode except for 
letters the string becomes garbled when the * qualifier is added, the only 
surviving character that is intact is ú.

Also, if you add \pN to the exceptions it additionally preserves the ó.

Verified on 5.2,5.3 and 5.3-SNAP.


Test script:
---
echo preg_replace('/[^\pL\pM]*/iu', '', 'áéíóú');
or
echo preg_replace('/[^\pL\pM\pN]*/iu', '', 'áéíóú');

Expected result:

áéíóú

Actual result:
--
����ú
or 
���óú (if \pN is added to the exceptions).






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53823&edit=1


Bug #53823 [Com]: preg_replace: * qualifier on unicode replace garbles the string

2012-02-25 Thread robertbasic dot com at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=53823&edit=1

 ID: 53823
 Comment by: robertbasic dot com at gmail dot com
 Reported by:keith at chaos-realm dot net
 Summary:preg_replace: * qualifier on unicode replace garbles
 the string
 Status: Verified
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.3SVN-2011-01-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Updated the test case showing that preg_filter and preg_replace_callback are 
affected, too.


Previous Comments:

[2012-02-24 23:33:34] robertbasic dot com at gmail dot com

I tried my best on this one. Tested against the trunk:
svn info | grep Revision
Revision: 323476

I created a test file for this, will attach.

I ran the following with gdb:

$ gdb sapi/cgi/php-cgi

and then set a breakpoint

(gdb) break php_pcre.c:1318

finally ran the test script like:

(gdb) run run-tests.php ext/pcre/tests/bug53823.phpt

On https://gist.github.com/1904467 I c/p-ed some output from gdb, but that 
might be incorrect as I'm fairly new to all this. Anyway, lines 12 and 22 in 
that gist caught my attention.

Also, I think the same issue exists for preg_filter, too.


[2011-01-26 08:02:54] ahar...@php.net

Verified on 5.3 and trunk.


[2011-01-23 18:10:44] tino dot didriksen at gmail dot com

...and then I forget to change the *. Let's try that again...

These work as expected:
echo preg_replace('/[^\pL\pM]+/iu', '', 'áéíóú');
echo preg_replace('/[^\pL\pM\pN]+/iu', '', 'áéíóú');


[2011-01-23 18:09:23] tino dot didriksen at gmail dot com

A workaround is to use + instead of *.

These work as expected:
echo preg_replace('/[^\pL\pM]*/iu', '', 'áéíóú');
echo preg_replace('/[^\pL\pM\pN]*/iu', '', 'áéíóú');


[2011-01-23 18:04:49] keith at chaos-realm dot net

.




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=53823


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53823&edit=1