Bug #65535 [Opn]: Non existent properties should be regular SimpleXMLElement objects
Edit report at https://bugs.php.net/bug.php?id=65535&edit=1
ID: 65535
User updated by: php at maisqi dot com
Reported by: php at maisqi dot com
Summary:Non existent properties should be regular
SimpleXMLElement objects
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Probably all
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
A simpler test script:
');
$node = $sx->node;
echo '1: $node = $sx->node => ', get_class ($node), "\n";
$node = $node->node;
echo '2: $node = $node->node => ', gettype ($node), "\n";
Previous Comments:
--------------------
[2013-08-23 15:10:50] php at maisqi dot com
Description:
When we invoke a non existent sub-node, SimpleXMLElement returns a
SimpleXMLElement object. But when we try to get a non existent sub-node on that
object, it returns NULL.
IMO this renderes it inconsistent.
Test script:
---
');
$node = $sx->node;
echo '1: $node = $sx->node => ', $node === $this ? 'this' :
gettype ($node) . ':' . get_class ($node), ' node->count: ', $node->count (),
"\n";
$node = $sx->node->node;
echo '2: $node = $node->node => ', $node === $this ? 'this' :
gettype ($node), "\n";
}
}
$x = new XXX;
$x->test ();
Expected result:
Or both ($sx and $node) SimpleXMLElement objects should return NULL for a non
existent sub-node or both sould return a SimpleXMLElement object. As it is,
it's a surprise lurking.
I think the second option is best. It makes things like this possible:
if ($products = $sx->Catalog->Products->Product) {
// Never gets here if there's no , or if it has no sub-nodes
// named , or if it has no sub-nodes named Product.
}
else die ('No products');
Actual result:
--
$node it's a SimpleXMLElement, then it is NULL.
1: $node = $sx->node => object:SimpleXMLElement node->count: 0
2: $node = $node->node => NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=65535&edit=1
[PHP-BUG] Bug #65535 [NEW]: Non existent properties should be regular SimpleXMLElement objects
From: php at maisqi dot com
Operating system: Probably all
PHP version: 5.4.19
Package: SimpleXML related
Bug Type: Bug
Bug description:Non existent properties should be regular SimpleXMLElement
objects
Description:
When we invoke a non existent sub-node, SimpleXMLElement returns a
SimpleXMLElement object. But when we try to get a non existent sub-node on
that object, it returns NULL.
IMO this renderes it inconsistent.
Test script:
---
');
$node = $sx->node;
echo '1: $node = $sx->node => ', $node === $this ? 'this' :
gettype
($node) . ':' . get_class ($node), ' node->count: ', $node->count (),
"\n";
$node = $sx->node->node;
echo '2: $node = $node->node => ', $node === $this ? 'this' :
gettype
($node), "\n";
}
}
$x = new XXX;
$x->test ();
Expected result:
Or both ($sx and $node) SimpleXMLElement objects should return NULL for a
non existent sub-node or both sould return a SimpleXMLElement object. As it
is, it's a surprise lurking.
I think the second option is best. It makes things like this possible:
if ($products = $sx->Catalog->Products->Product) {
// Never gets here if there's no , or if it has no sub-nodes
// named , or if it has no sub-nodes named Product.
}
else die ('No products');
Actual result:
--
$node it's a SimpleXMLElement, then it is NULL.
1: $node = $sx->node => object:SimpleXMLElement node->count: 0
2: $node = $node->node => NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=65535&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65535&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65535&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65535&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65535&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65535&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65535&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65535&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65535&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65535&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65535&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65535&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65535&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65535&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65535&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65535&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65535&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65535&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65535&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65535&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65535&r=mysqlcfg
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1 ID: 61336 Comment by: php at maisqi dot com Reported by:ram...@php.net Summary:file_get_contents() no longer returns false on 4xx responses Status: Open Type: Bug Package:Filesystem function related Operating System: CentOS 6.2 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Just noted that I gave a wrong URI to the script; sorry, here is the right one: http://maisqi.com/outros/bugs/php/61336 Previous Comments: [2013-03-04 15:01:49] php at maisqi dot com vestigalorgan, you are right: it should return false in all three cases. Thanks for correcting. [2013-03-02 01:50:21] vestigalorgan at gmail dot com I've run the test case that maisqi provided, and here are my results: 1. Using file_file_get_contents() on an non-existing resource on a existing domain: The result: boolean $http_response_header: array 2. Using file_file_get_contents() on a non-existing domain, with follow_location => 0 on the context: The result: boolean $http_response_header: NULL 3. Using file_file_get_contents() on a non-existing domain, __without__ follow_location => 0 on the context: The result: boolean $http_response_header: NULL This is on Ubuntu 12.04 LTS 64-bit with Apache 2.2.22 and PHP 5.3.10-1ubuntu3.5 with the Suhosin-Patch. Everything appears to be working fine there. Shouldn't the output of the results be a boolean false, not NULL, maisqi? [2013-03-01 09:54:17] php at maisqi dot com I think I have new info on this issue. If you check the URI at the bottom you'll find three tests: 1. Using file_file_get_contents() on an non-existing resource on a existing domain: Result: empty string $http_response_header : an array 2. Using file_file_get_contents() on a non-existing domain, with follow_location => 0 on the context: Result: empty string $http_response_header : NULL 3. Using file_file_get_contents() on a non-existing domain, __without__ follow_location => 0 on the context: Result: non empty string $http_response_header : an array I'd expect that all the results should be NULL. I think the problem has to to with idiosyncratic behavior on some internal library. In the third test we can see that there's something asking OpenDNS when trying to deal with the non-existing behavior; and then it sends a Location header. This behavior is not documented. - The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected; - On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected; - On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it works as expected; - On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected. So I'd say it has to do with the underlying system libraries and configuration; it would be nice if others test the script on other kind of servers... Test script: http://maisqi/outros/bugs/php/61336 [CentOS / PHP 5.4.11] [2013-01-14 23:52:39] vestigalorgan at gmail dot com I'm experiencing a similar issue in the PHP version 5.4.7 that ships with XAMPP. When I open a web URL that throws a warning such as "Warning: file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream: No connection could be made because the target machine actively refused it.", file_get_contents() returns an empty string, instead of false. I'm not sure if this is related to this bug or I should file a new one. I'm experiencing this on Windows 7 Professional, SP1 32-bit. I'm only using the first parameter of file_get_contents(). [2012-10-18 15:51:46] stasismedia at gmail dot com I should add... Both PHP versions in Ubuntu 12.04 x64 running as a guest in Virtualbox. 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=61336 -- Edit this bug report at https://bugs.php.net/bug.php?id=61336&edit=1
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: php at maisqi dot com
Reported by:ram...@php.net
Summary:file_get_contents() no longer returns false on 4xx
responses
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: CentOS 6.2
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
vestigalorgan, you are right: it should return false in all three cases. Thanks
for correcting.
Previous Comments:
[2013-03-02 01:50:21] vestigalorgan at gmail dot com
I've run the test case that maisqi provided, and here are my results:
1. Using file_file_get_contents() on an non-existing resource on a existing
domain:
The result: boolean
$http_response_header: array
2. Using file_file_get_contents() on a non-existing domain, with
follow_location => 0 on the context:
The result: boolean
$http_response_header: NULL
3. Using file_file_get_contents() on a non-existing domain, __without__
follow_location => 0 on the context:
The result: boolean
$http_response_header: NULL
This is on Ubuntu 12.04 LTS 64-bit with Apache 2.2.22 and PHP 5.3.10-1ubuntu3.5
with the Suhosin-Patch. Everything appears to be working fine there.
Shouldn't the output of the results be a boolean false, not NULL, maisqi?
[2013-03-01 09:54:17] php at maisqi dot com
I think I have new info on this issue. If you check the URI at the bottom
you'll find three tests:
1. Using file_file_get_contents() on an non-existing resource on a existing
domain:
Result: empty string
$http_response_header : an array
2. Using file_file_get_contents() on a non-existing domain, with
follow_location => 0 on the context:
Result: empty string
$http_response_header : NULL
3. Using file_file_get_contents() on a non-existing domain, __without__
follow_location => 0 on the context:
Result: non empty string
$http_response_header : an array
I'd expect that all the results should be NULL.
I think the problem has to to with idiosyncratic behavior on some internal
library. In the third test we can see that there's something asking OpenDNS
when trying to deal with the non-existing behavior; and then it sends a
Location header. This behavior is not documented.
- The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected;
- On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected;
- On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it
works as expected;
- On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected.
So I'd say it has to do with the underlying system libraries and configuration;
it would be nice if others test the script on other kind of servers...
Test script: http://maisqi/outros/bugs/php/61336
[CentOS / PHP 5.4.11]
[2013-01-14 23:52:39] vestigalorgan at gmail dot com
I'm experiencing a similar issue in the PHP version 5.4.7 that ships with
XAMPP. When I open a web URL that throws a warning such as "Warning:
file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream:
No connection could be made because the target machine actively refused it.",
file_get_contents() returns an empty string, instead of false.
I'm not sure if this is related to this bug or I should file a new one. I'm
experiencing this on Windows 7 Professional, SP1 32-bit. I'm only using the
first parameter of file_get_contents().
[2012-10-18 15:51:46] stasismedia at gmail dot com
I should add...
Both PHP versions in Ubuntu 12.04 x64 running as a guest in Virtualbox.
[2012-10-18 15:43:27] stasismedia at gmail dot com
I actually get the same issue on both 5.3.11 and 5.4.4:
5.3.11:
---
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Thu, 18 Oct 2012 15:35:04 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Fri, 18-Oct-2013 15:35:04 GMT;
path=/; domain=.php.net"
[6]=>
string(101) "Set-Cookie: COUNTRY=GBR%2C94.195.8.27; expires=Thu, 25-Oct-2012
15:35:04 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Leng
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: php at maisqi dot com
Reported by:ram...@php.net
Summary:file_get_contents() no longer returns false on 4xx
responses
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: CentOS 6.2
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I think I have new info on this issue. If you check the URI at the bottom
you'll find three tests:
1. Using file_file_get_contents() on an non-existing resource on a existing
domain:
Result: empty string
$http_response_header : an array
2. Using file_file_get_contents() on a non-existing domain, with
follow_location => 0 on the context:
Result: empty string
$http_response_header : NULL
3. Using file_file_get_contents() on a non-existing domain, __without__
follow_location => 0 on the context:
Result: non empty string
$http_response_header : an array
I'd expect that all the results should be NULL.
I think the problem has to to with idiosyncratic behavior on some internal
library. In the third test we can see that there's something asking OpenDNS
when trying to deal with the non-existing behavior; and then it sends a
Location header. This behavior is not documented.
- The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected;
- On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected;
- On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it
works as expected;
- On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected.
So I'd say it has to do with the underlying system libraries and configuration;
it would be nice if others test the script on other kind of servers...
Test script: http://maisqi/outros/bugs/php/61336
[CentOS / PHP 5.4.11]
Previous Comments:
[2013-01-14 23:52:39] vestigalorgan at gmail dot com
I'm experiencing a similar issue in the PHP version 5.4.7 that ships with
XAMPP. When I open a web URL that throws a warning such as "Warning:
file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream:
No connection could be made because the target machine actively refused it.",
file_get_contents() returns an empty string, instead of false.
I'm not sure if this is related to this bug or I should file a new one. I'm
experiencing this on Windows 7 Professional, SP1 32-bit. I'm only using the
first parameter of file_get_contents().
[2012-10-18 15:51:46] stasismedia at gmail dot com
I should add...
Both PHP versions in Ubuntu 12.04 x64 running as a guest in Virtualbox.
[2012-10-18 15:43:27] stasismedia at gmail dot com
I actually get the same issue on both 5.3.11 and 5.4.4:
5.3.11:
---
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Thu, 18 Oct 2012 15:35:04 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Fri, 18-Oct-2013 15:35:04 GMT;
path=/; domain=.php.net"
[6]=>
string(101) "Set-Cookie: COUNTRY=GBR%2C94.195.8.27; expires=Thu, 25-Oct-2012
15:35:04 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4182"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4182) "
string(22) "HTTP/1.1 404 Not Found"
[1] =>
string(35) "Date: Thu, 18 Oct 2012 15:35:19 GMT"
[2] =>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3] =>
string(23) "X-Powered-By: PHP/5.3.2"
[4] =>
string(20) "Content-language: en"
[5] =>
string(88) "Set-Cookie: LAST_LANG=en; expires=Fri, 18-Oct-2013 15:35:19 GMT;
path=/; domain=.php.net"
[6] =>
string(101) "Set-Cookie: COUNTRY=GBR%2C94.195.8.27; expires=Thu, 25-Oct-2012
15:35:19 GMT; path=/; domain=.php.net"
[7] =>
string(21) "Status: 404 Not Found"
[8] =>
string(20) "Content-Length: 4182"
[9] =>
string(17) "Connection: close"
[10] =>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4182) "https://bugs.php.net/bug.php?id=61336
--
Edit this bug report at https://bugs.php.net/bug.php?id=61336&edit=1
[PHP-BUG] Bug #64312 [NEW]: set_error_handler always return handler if called inside an error_handler
From: php at maisqi dot com
Operating system: Win7 32 bits
PHP version: 5.4.12
Package: *General Issues
Bug Type: Bug
Bug description:set_error_handler always return handler if called inside an
error_handler
Description:
If you set an error handler when inside an error handling function,
set_error_handler will always return NULL.
Test script:
---
', gettype
(set_error_handler
('second_handler')), "\n";
echo "\n\n", '$y = $o', "\n";
$y = $o;
}
function second_handler () {
echo " second_handler\n";
}
set_error_handler ('first_handler');
echo '$x = $y', "\n";
$x = $y;
echo ' Set to other handler: ', gettype (set_error_handler
(function(){})), "\n";
Expected result:
set_error_handler should return the name of the error handling function,
which in this case would be the name of the running function.
Actual result:
--
It just returns null.
--
Edit bug report at https://bugs.php.net/bug.php?id=64312&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64312&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64312&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64312&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64312&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64312&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64312&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64312&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64312&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64312&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64312&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64312&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64312&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64312&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64312&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64312&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64312&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64312&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64312&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64312&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64312&r=mysqlcfg
Bug #64312 [Com]: set_error_handler always return handler if called inside an error_handler
Edit report at https://bugs.php.net/bug.php?id=64312&edit=1
ID: 64312
Comment by: php at maisqi dot com
Reported by: php at maisqi dot com
Summary:set_error_handler always return handler if called
inside an error_handler
Status: Open
Type: Bug
Package:*General Issues
Operating System: Win7 32 bits
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Test script: http://maisqi.com/outros/bugs/php/64312
Previous Comments:
[2013-02-27 15:43:04] php at maisqi dot com
Description:
If you set an error handler when inside an error handling function,
set_error_handler will always return NULL.
Test script:
---
', gettype
(set_error_handler ('second_handler')), "\n";
echo "\n\n", '$y = $o', "\n";
$y = $o;
}
function second_handler () {
echo " second_handler\n";
}
set_error_handler ('first_handler');
echo '$x = $y', "\n";
$x = $y;
echo ' Set to other handler: ', gettype (set_error_handler
(function(){})), "\n";
Expected result:
set_error_handler should return the name of the error handling function, which
in this case would be the name of the running function.
Actual result:
--
It just returns null.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64312&edit=1
Bug #52339 [Com]: SPL autoloader breaks class_exists()
Edit report at https://bugs.php.net/bug.php?id=52339&edit=1 ID: 52339 Comment by: php at maisqi dot com Reported by:dangerous dot ben at gmail dot com Summary:SPL autoloader breaks class_exists() Status: Re-Opened Type: Bug Package:SPL related Operating System: any (debian) PHP Version:5.3.3RC2 Block user comment: N Private report: N New Comment: This is clearly a bug. We're testing if a class exists not asserting it. There's seam to be a patch for this. Any chance it will be accepted? Previous Comments: [2012-11-24 20:29:04] ciantic at oksidi dot com Is this bug still happening in PHP5.4 and greater? I'm using 5.3.8. If one uses class_exists it should never throw error, only true or false. It makes no sense otherwise. This is one of those where setting of some other application can totally broke functionality elsewhere. Should everyone using class_exists catch try LogicException too? I'd argue not. Though the workaround (empty function for spl) is kind of nice, as dangerous dot ben mentioned. [2012-08-08 16:18:39] kilbyc at bellsouth dot net Even worse. The no arg register is inconsistent. If the autoload stack is empty by the time the no arg registered is called, how can it function differently than if the autoload stack has been emptied by the time the no arg register is called? This is nonsensical behavior, and manual for spl_autoload say nothing about it throwing. Let alone LogicException. I would have expected this to be a RuntimeException. As it depends on the specific environment it is run in as to whether or not spl_autoload will find something. [2012-08-08 16:02:40] kilbyc at bellsouth dot net PHP 5.3.8 (cli) (built: Aug 23 2011 11:50:20) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies spl_autoload is inconsistent with itself. [2012-03-16 22:02:29] pwolfenden at qualys dot com Although I have not yet migrated to 5.3, I care about this bug because I'm using an autoload function (in 5.2) which contains some directory traversal logic and uses class_exists() to decide whether or not to keep looking. I need to do this because I'm in the scenario described by james (and so cannot assume that all the package files in my codebase follow my preferred naming convention), and I would much prefer class_exists() to continue to return false rather than having it throw a new Exception. [2012-02-03 00:01:46] frozenf...@php.net Re-opening, as there still exists the conflict of class_exists() generating an error when autoloading fails, which is a chicken and the egg sort of issue. If one wants to try autoloading if the class doesn't exist, but autoloading fails, it should be possible to recover from that failure. My understanding of the underlying code is that it generates an error in this case. Perhaps it should generate an exception, which can be caught an handled. 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=52339 -- Edit this bug report at https://bugs.php.net/bug.php?id=52339&edit=1
Bug #60560 [Com]: SplFixedArray un-/serialize, getSize(), count() return 0, keys are strings
Edit report at https://bugs.php.net/bug.php?id=60560&edit=1
ID: 60560
Comment by: php at maisqi dot com
Reported by:digital1kk at interia dot pl
Summary:SplFixedArray un-/serialize, getSize(), count()
return 0, keys are strings
Status: Closed
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Hello. This is not really fixed. I still got this error on PHP 5.4.5. I don't
believe that the said fix wasn't released in six months, so something is wrong.
So, is this going to be reopen or should I file a new bug?
Previous Comments:
[2012-06-18 15:57:56] php at maisqi dot com
Hello. I'm experiencing this problem in Windows and Linux, PHP 5.4.4 and PHP
5.3.3. I argue it's not resolved again.
I wrote a demo at http://maisqi.com/outros/bugs/php/SplFixedArraySerialization
and I'd appreciate if someone else makes his own tests. Here is the demo source
code:
SplFixedArray Serialization
An unserialized SplFixedArray loses it's element count, though it keeps
the
elements. This seems to be
https://bugs.php.net/bug.php?id=60560&edit=1";>Bug
#60560 all
over again.
This demo runs on a PHP 5.3.3 CGI under Apache and Linux. Also tested it
on a PHP 5.4.4 running as a Apache 2 module under Windows 7 32 bits,
with
same results.
SplFixedArray to serialize:\n";
print_r ($x);
echo "\ncount: ", $x->getSize (), "";
echo "\nFirst element: ";
try { $o = $x [0];} catch (Exception $e) {$o = 'Error!'; }
echo "$o\n";
echo "\n\nSerializing to file \"$fn\"...\n";
file_put_contents ($fn, serialize ($x));
echo "\n\nUnserializing from file \"$fn\"...\n";
$x = unserialize (file_get_contents ($fn));
echo "\n\nUnserialized SplFixedArray:\n";
print_r ($x);
echo "\ncount: ", $x->getSize (), "";
echo "\nFirst element: ";
try { $o = $x [0];} catch (Exception $e) {$o = 'Error!'; }
echo "$o\n";
if ($buf = @file_get_contents ('error_log')) {
echo "\n\nLast errors:\n", $buf;
}
?>
[2012-02-21 10:34:50] ahar...@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.
Fixed on trunk.
[2012-02-21 10:34:39] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=323408
Log: Add a __wakeup() method to SplFixedArray, thereby fixing serialising an
SplFixedArray object and bug #60560 (SplFixedArray un-/serialize, getSize(),
count() return 0, keys are strings).
[2011-12-19 13:49:25] digital1kk at interia dot pl
Quick fix is to store in serialized form internal array:
-
$sa = serialize($a->toArray());
$ua = unserialize($sa);
$b = SplFixedArray::fromArray($ua);
var_dump($b);
echo 'Sizeof $b = ' . $b->getSize(), PHP_EOL;
echo 'Count $b = ' . $b->count(), PHP_EOL;
-
Gives the expected results
Also I forgot in php >= 5.4.0RC3 (should I report this as separate bug?)
The actual result of var_dump($b) is:
$b = object(SplFixedArray)#2 (2) {
["0"]=>
int(1)
["1"]=>
int(2)
}
The keys are strings and not integers and this causes
-
$b = unserialize(serialize($a));
SplFixedArray::fromArray($b->toarray());
-
To throw an exception 'InvalidArgumentException' with message 'array must
contain only positive integer keys'
[2011-12-19 10:31:53] digital1kk at interia dot pl
Description:
If SplFixedArray object is created via unserialize() of serialized instance
then the getSize() and count() methods return 0 instead of expected actual size.
Tested on Debian Squeeze 6 64bit:
x86-5.4.0RC3-dev
Tested on windows 7 64bit:
x86-5.4.0RC3-nts
x86-5.4.0trunk(12.12)-nts
x86-5.4.0snap(13.12)-nts
x86-5.3.8-nts
x86-5.3.6-ts
x86-5.3.6-nts
x64-5.3.6-nts
x86-5.3.4-nts
x86-5.3.1-ts
Test script:
-
Bug #54940 [Com]: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4
Edit report at https://bugs.php.net/bug.php?id=54940&edit=1
ID: 54940
Comment by: php at maisqi dot com
Reported by: php at maisqi dot com
Summary:Corrupt JPEG data: 200 extraneous bytes before
marker 0xc4
Status: Open
Type: Bug
Package:GD related
Operating System: Windows XP 32
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
As with bug 39918, this can be solved with:
ini_set ('gd.jpeg_ignore_warning', 1);
Please close this entry. Sorry for the bogus.
Previous Comments:
[2011-08-07 18:13:41] php at maisqi dot com
Hello? Anyone?
[2011-05-27 14:13:59] php at maisqi dot com
Here's the JPEG: http://www.maisqi.com/954.jpg
[2011-05-27 14:10:34] php at maisqi dot com
Description:
I noticed that imagecreatefromjpeg() failed loading some JPEGs. I thought the
files were corrupt, but then I successfully opened them on The Gimp.
I noticed that if I opened one of those files on The Gimp and just saved it
(without doing any modifications), imagecreatefromjpeg() would open the saved
file with no problems.
So, It's clear that some JPEGs are a little different from the others and that
The Gimp fixes them on saving.
imagecreatefromjpeg() issues the following warnings:
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg,
libjpeg: recoverable error: Corrupt JPEG data: 200 extraneous bytes before
marker 0xc4 in exp.php on line 3
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '954.jpg' is not
a valid JPEG file in exp.php on line 3
PS: I've found bug 39918 similar to this. The problems seam to be related but
not the same. The first warnings looks like issued by a lower level function
and states that the error is recoverable.
Test script:
---
https://bugs.php.net/bug.php?id=54940&edit=1
Bug #60560 [Com]: SplFixedArray un-/serialize, getSize(), count() return 0, keys are strings
Edit report at https://bugs.php.net/bug.php?id=60560&edit=1
ID: 60560
Comment by: php at maisqi dot com
Reported by:digital1kk at interia dot pl
Summary:SplFixedArray un-/serialize, getSize(), count()
return 0, keys are strings
Status: Closed
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Hello. I'm experiencing this problem in Windows and Linux, PHP 5.4.4 and PHP
5.3.3. I argue it's not resolved again.
I wrote a demo at http://maisqi.com/outros/bugs/php/SplFixedArraySerialization
and I'd appreciate if someone else makes his own tests. Here is the demo source
code:
SplFixedArray Serialization
An unserialized SplFixedArray loses it's element count, though it keeps
the
elements. This seems to be
https://bugs.php.net/bug.php?id=60560&edit=1";>Bug
#60560 all
over again.
This demo runs on a PHP 5.3.3 CGI under Apache and Linux. Also tested it
on a PHP 5.4.4 running as a Apache 2 module under Windows 7 32 bits,
with
same results.
SplFixedArray to serialize:\n";
print_r ($x);
echo "\ncount: ", $x->getSize (), "";
echo "\nFirst element: ";
try { $o = $x [0];} catch (Exception $e) {$o = 'Error!'; }
echo "$o\n";
echo "\n\nSerializing to file \"$fn\"...\n";
file_put_contents ($fn, serialize ($x));
echo "\n\nUnserializing from file \"$fn\"...\n";
$x = unserialize (file_get_contents ($fn));
echo "\n\nUnserialized SplFixedArray:\n";
print_r ($x);
echo "\ncount: ", $x->getSize (), "";
echo "\nFirst element: ";
try { $o = $x [0];} catch (Exception $e) {$o = 'Error!'; }
echo "$o\n";
if ($buf = @file_get_contents ('error_log')) {
echo "\n\nLast errors:\n", $buf;
}
?>
Previous Comments:
[2012-02-21 10:34:50] ahar...@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.
Fixed on trunk.
[2012-02-21 10:34:39] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=323408
Log: Add a __wakeup() method to SplFixedArray, thereby fixing serialising an
SplFixedArray object and bug #60560 (SplFixedArray un-/serialize, getSize(),
count() return 0, keys are strings).
[2011-12-19 13:49:25] digital1kk at interia dot pl
Quick fix is to store in serialized form internal array:
-
$sa = serialize($a->toArray());
$ua = unserialize($sa);
$b = SplFixedArray::fromArray($ua);
var_dump($b);
echo 'Sizeof $b = ' . $b->getSize(), PHP_EOL;
echo 'Count $b = ' . $b->count(), PHP_EOL;
-
Gives the expected results
Also I forgot in php >= 5.4.0RC3 (should I report this as separate bug?)
The actual result of var_dump($b) is:
$b = object(SplFixedArray)#2 (2) {
["0"]=>
int(1)
["1"]=>
int(2)
}
The keys are strings and not integers and this causes
-
$b = unserialize(serialize($a));
SplFixedArray::fromArray($b->toarray());
-
To throw an exception 'InvalidArgumentException' with message 'array must
contain only positive integer keys'
[2011-12-19 10:31:53] digital1kk at interia dot pl
Description:
If SplFixedArray object is created via unserialize() of serialized instance
then the getSize() and count() methods return 0 instead of expected actual size.
Tested on Debian Squeeze 6 64bit:
x86-5.4.0RC3-dev
Tested on windows 7 64bit:
x86-5.4.0RC3-nts
x86-5.4.0trunk(12.12)-nts
x86-5.4.0snap(13.12)-nts
x86-5.3.8-nts
x86-5.3.6-ts
x86-5.3.6-nts
x64-5.3.6-nts
x86-5.3.4-nts
x86-5.3.1-ts
Test script:
---
getSize(), PHP_EOL;
echo 'Count $a = ' . $a->count(), PHP_EOL;
echo PHP_EOL;
$b = unserialize(serialize($a));
echo '$b = ', var_dump($b);
echo 'Sizeof $b = ' . $b->getSize(), PHP_EOL;
echo 'Count $b = ' . $b->count(), PHP_EOL;
Expected result:
$a = object(SplFixedArray)
Bug #55837 [Opn]: Glob skips utf8 file names after setlocale en_US.UTF-8
Edit report at https://bugs.php.net/bug.php?id=55837&edit=1 ID: 55837 User updated by: php at maisqi dot com Reported by: php at maisqi dot com Summary:Glob skips utf8 file names after setlocale en_US.UTF-8 Status: Open Type: Bug Package:Filesystem function related Operating System: CentOS release 5.7 (Final) PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Please download the archive from: http://www.maisqi.com/glob-locale-test.tgz Previous Comments: [2011-10-03 15:34:04] php at maisqi dot com Description: The title says it all. I think it will be faster if you run the test I attached. Gunzip the archive on a Linux Server and run glob-locale-test.php. You can see it directly on http://www.maisqi.com/glob-locale-test.php Test script: --- See the script on the attached archive (glob-locale-test.php). It tries to list the files on the associated folder (that is also on the archive) three times. 1. The first one uses glob with the default locale. 2. The second, also uses glob but after the locale has been set to en_US.UTF-8. 3. The third, uses DirectoryIterator. Expected result: All tries should list 5 files. Actual result: -- The second try only prints the file with a ascii file name. -- Edit this bug report at https://bugs.php.net/bug.php?id=55837&edit=1
[PHP-BUG] Bug #55837 [NEW]: Glob skips utf8 file names after setlocale en_US.UTF-8
From: Operating system: CentOS release 5.7 (Final) PHP version: 5.3.8 Package: Filesystem function related Bug Type: Bug Bug description:Glob skips utf8 file names after setlocale en_US.UTF-8 Description: The title says it all. I think it will be faster if you run the test I attached. Gunzip the archive on a Linux Server and run glob-locale-test.php. You can see it directly on http://www.maisqi.com/glob-locale-test.php Test script: --- See the script on the attached archive (glob-locale-test.php). It tries to list the files on the associated folder (that is also on the archive) three times. 1. The first one uses glob with the default locale. 2. The second, also uses glob but after the locale has been set to en_US.UTF-8. 3. The third, uses DirectoryIterator. Expected result: All tries should list 5 files. Actual result: -- The second try only prints the file with a ascii file name. -- Edit bug report at https://bugs.php.net/bug.php?id=55837&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55837&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55837&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55837&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55837&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55837&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55837&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55837&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55837&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55837&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55837&r=support Expected behavior: https://bugs.php.net/fix.php?id=55837&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55837&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55837&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55837&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55837&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55837&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55837&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55837&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55837&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55837&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55837&r=mysqlcfg
Bug #54940 [Com]: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4
Edit report at https://bugs.php.net/bug.php?id=54940&edit=1 ID: 54940 Comment by: php at maisqi dot com Reported by: php at maisqi dot com Summary:Corrupt JPEG data: 200 extraneous bytes before marker 0xc4 Status: Open Type: Bug Package:GD related Operating System: Windows XP 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Hello? Anyone? Previous Comments: [2011-05-27 14:13:59] php at maisqi dot com Here's the JPEG: http://www.maisqi.com/954.jpg [2011-05-27 14:10:34] php at maisqi dot com Description: I noticed that imagecreatefromjpeg() failed loading some JPEGs. I thought the files were corrupt, but then I successfully opened them on The Gimp. I noticed that if I opened one of those files on The Gimp and just saved it (without doing any modifications), imagecreatefromjpeg() would open the saved file with no problems. So, It's clear that some JPEGs are a little different from the others and that The Gimp fixes them on saving. imagecreatefromjpeg() issues the following warnings: Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4 in exp.php on line 3 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '954.jpg' is not a valid JPEG file in exp.php on line 3 PS: I've found bug 39918 similar to this. The problems seam to be related but not the same. The first warnings looks like issued by a lower level function and states that the error is recoverable. Test script: --- https://bugs.php.net/bug.php?id=54940&edit=1
Bug #54940 [Com]: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4
Edit report at http://bugs.php.net/bug.php?id=54940&edit=1 ID: 54940 Comment by: php at maisqi dot com Reported by: php at maisqi dot com Summary:Corrupt JPEG data: 200 extraneous bytes before marker 0xc4 Status: Open Type: Bug Package:GD related Operating System: Windows XP 32 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Here's the JPEG: http://www.maisqi.com/954.jpg Previous Comments: [2011-05-27 14:10:34] php at maisqi dot com Description: I noticed that imagecreatefromjpeg() failed loading some JPEGs. I thought the files were corrupt, but then I successfully opened them on The Gimp. I noticed that if I opened one of those files on The Gimp and just saved it (without doing any modifications), imagecreatefromjpeg() would open the saved file with no problems. So, It's clear that some JPEGs are a little different from the others and that The Gimp fixes them on saving. imagecreatefromjpeg() issues the following warnings: Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4 in exp.php on line 3 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '954.jpg' is not a valid JPEG file in exp.php on line 3 PS: I've found bug 39918 similar to this. The problems seam to be related but not the same. The first warnings looks like issued by a lower level function and states that the error is recoverable. Test script: --- http://bugs.php.net/bug.php?id=54940&edit=1
[PHP-BUG] Bug #54940 [NEW]: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4
From: Operating system: Windows XP 32 PHP version: 5.3.6 Package: GD related Bug Type: Bug Bug description:Corrupt JPEG data: 200 extraneous bytes before marker 0xc4 Description: I noticed that imagecreatefromjpeg() failed loading some JPEGs. I thought the files were corrupt, but then I successfully opened them on The Gimp. I noticed that if I opened one of those files on The Gimp and just saved it (without doing any modifications), imagecreatefromjpeg() would open the saved file with no problems. So, It's clear that some JPEGs are a little different from the others and that The Gimp fixes them on saving. imagecreatefromjpeg() issues the following warnings: Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 200 extraneous bytes before marker 0xc4 in exp.php on line 3 Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '954.jpg' is not a valid JPEG file in exp.php on line 3 PS: I've found bug 39918 similar to this. The problems seam to be related but not the same. The first warnings looks like issued by a lower level function and states that the error is recoverable. Test script: --- http://bugs.php.net/bug.php?id=54940&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54940&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54940&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54940&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54940&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54940&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54940&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54940&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54940&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54940&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54940&r=support Expected behavior: http://bugs.php.net/fix.php?id=54940&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54940&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54940&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54940&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54940&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54940&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54940&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54940&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54940&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54940&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54940&r=mysqlcfg
[PHP-BUG] Bug #54842 [NEW]: ceil yields a negative zero
From:
Operating system: Windows XP32
PHP version: 5.3.6
Package: *Math Functions
Bug Type: Bug
Bug description:ceil yields a negative zero
Description:
When doing some math with dates and "ceiling" the result, I got a negative
zero!
I don't understand how that can be, so I presume it's an error.
Test script:
---
';
echo 'base: ', date ('Y-m-d', $base), '';
echo '';
echo 'dt - base: ', ceil (($dt - $base) / 86400), '';
?>
It outputs "-0" on PHP 5.3.6, under Windows XP 32 bits
Expected result:
The bolded text should be "0" (zero)
Actual result:
--
The bolded text is "-0" (negative zero)
--
Edit bug report at http://bugs.php.net/bug.php?id=54842&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54842&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54842&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54842&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54842&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54842&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54842&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54842&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54842&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54842&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54842&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54842&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54842&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54842&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54842&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54842&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54842&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54842&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54842&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54842&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54842&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54842&r=mysqlcfg
[PHP-BUG] Bug #53958 [NEW]: Closures can't 'use' shared variables by value and by reference
From:
Operating system: Windows XP 32
PHP version: 5.3.5
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Closures can't 'use' shared variables by value and by reference
Description:
When the same variable is 'used' by one closure by reference an another
closure 'uses' the same variable by value, both behave like were 'using'
the var by value. I think the demonstration code will help making things
clear for you.
Not less stranger is the fact that the order you declare the closures
matters.
Test script:
---
"; };
$fn2 = function () use ($a) { echo $a . "\n"; };
$a = 123;
$fn1 ();
$fn2 ();
//
// Analisys:
// In PHP 5.3.5 under Windows, outputs:
// 123, 123
// Ok.
///
///
/// TEST 3
///
// Let's repeat TEST 1, but this time both closures 'use' $a by reference.
echo "-\n";
$a = 123;
$fn1 = function () use (&$a) { echo $a . "\n"; };
$fn2 = function () use (&$a) { echo $a . "\n"; };
$a = 456;
$fn1 ();
$fn2 ();
//
// Analisys:
// In PHP 5.3.5 under Windows, outputs:
// 456, 456
// Ok.
///
///
/// TEST 3
///
/// Let's repeat TEST 1, but this time closure 1 'uses' $a by reference
/// closure 2 uses it by value.
///
echo "-\n";
$a = 123;
$fn1 = function () use (&$a) { echo $a . "\n"; };
$fn2 = function () use ($a) { echo $a . "\n"; };
$a = 456;
$fn1 ();
$fn2 ();
//
// Analisys:
// In PHP 5.3.5 under Windows, outputs:
// 123, 123
// Wrong! It should output 456, 123.
///
///
/// TEST 4
///
/// Let's do same as in TEST 3 but now closure 1 'uses' by value and
closure 2
/// 'uses' by reference.
///
echo "-\n";
$a = 123;
$fn1 = function () use ($a) { echo $a . "\n"; };
$fn2 = function () use (&$a) { echo $a . "\n"; };
$a = 456;
$fn1 ();
$fn2 ();
//
// Analisys:
// In PHP 5.3.5 under Windows, outputs:
// 123, 456
// Ok. What the hell?
Expected result:
It should output:
123
123
-
456
456
-
456
123
-
123
456
Actual result:
--
Only Test 3 fails. The others are for helping finding the problem.
123
123
-
456
456
-
123
123
-
123
456
--
Edit bug report at http://bugs.php.net/bug.php?id=53958&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53958&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53958&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53958&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53958&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53958&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53958&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53958&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53958&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53958&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53958&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53958&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53958&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53958&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53958&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53958&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53958&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53958&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53958&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53958&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53958&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53958&r=mysqlcfg
