[PHP-BUG] Bug #65150 [NEW]: DateTime subclasses expose extra properties
From: mike at silverorange dot com
Operating system: CentOS or RHEL
PHP version: 5.3.26
Package: Date/time related
Bug Type: Bug
Bug description:DateTime subclasses expose extra properties
Description:
I expected the DateTime class properties to be private or at least
protected so
users of my subclass don't get internals exposed.
See also https://bugs.php.net/bug.php?id=49382
Test script:
---
class MyDate extends DateTime
{
public $extra = '';
}
$d = new MyDate('2013-01-01', new DateTimeZone('UTC'));
var_dump($d);
Expected result:
class MyDate#1 (4) {
public $extra =>
string(0) ""
}
Actual result:
--
class MyDate#1 (4) {
public $extra =>
string(0) ""
public $date =>
string(19) "2013-01-01 00:00:00"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}
--
Edit bug report at https://bugs.php.net/bug.php?id=65150&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65150&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65150&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65150&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65150&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65150&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65150&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65150&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65150&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65150&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65150&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65150&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65150&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65150&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65150&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65150&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65150&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65150&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65150&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65150&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65150&r=mysqlcfg
[PHP-BUG] Bug #65151 [NEW]: DateTime subclasses cant use custom serializer
From: mike at silverorange dot com
Operating system: CentOS or RHEL
PHP version: 5.3.26
Package: Date/time related
Bug Type: Bug
Bug description:DateTime subclasses cant use custom serializer
Description:
If a DateTime subclass implements Serializable it cant be unserialized. A
PHP
warning is raised when restoring the time zone is attempted.
Test script:
---
class MyDate extends DateTime implements Serializable
{
public function serialize()
{
$data = array(
$this->getTimestamp(),
$this->dateTimezone()->getName()
);
return serialize($data);
}
public function unserialize($data)
{
$data = unserialize($data);
$this->setTimestamp($data[0]);
$this->setTimezone(new DateTimeZone($data[1]));
}
}
$d = new MyDate('2013-01-01', new DateTimeZone('UTC'));
echo unserialize(serialize($d))->format('c');
Expected result:
2013-01-01T00:00:00+00:00
Actual result:
--
Warning: DateTime::setTimezone(): The DateTime object has not been
correctly
initialized by its constructor
--
Edit bug report at https://bugs.php.net/bug.php?id=65151&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65151&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65151&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65151&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65151&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65151&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65151&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65151&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65151&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65151&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65151&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65151&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65151&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65151&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65151&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65151&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65151&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65151&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65151&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65151&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65151&r=mysqlcfg
Bug #65150 [Nab]: DateTime subclasses expose extra properties
Edit report at https://bugs.php.net/bug.php?id=65150&edit=1
ID: 65150
User updated by:mike at silverorange dot com
Reported by:mike at silverorange dot com
Summary:DateTime subclasses expose extra properties
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: CentOS or RHEL
PHP Version:5.3.26
Block user comment: N
Private report: N
New Comment:
The properties are not exposed on regular DateTime objects, only on subclasses.
The exposed properties are also read-only which is unintuitive for PHP userland
developers.
Previous Comments:
[2013-06-28 17:30:13] a...@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
The properties are exposed intentionally, so that's ok. To achieve teh goal
you've
described the proper way were to use an appropriate design pattern, maybe
Facade
or Proxy.
[2013-06-27 21:04:03] mike at silverorange dot com
Description:
I expected the DateTime class properties to be private or at least protected so
users of my subclass don't get internals exposed.
See also https://bugs.php.net/bug.php?id=49382
Test script:
---
class MyDate extends DateTime
{
public $extra = '';
}
$d = new MyDate('2013-01-01', new DateTimeZone('UTC'));
var_dump($d);
Expected result:
class MyDate#1 (4) {
public $extra =>
string(0) ""
}
Actual result:
--
class MyDate#1 (4) {
public $extra =>
string(0) ""
public $date =>
string(19) "2013-01-01 00:00:00"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65150&edit=1
Bug #65150 [Nab]: DateTime subclasses expose extra properties
Edit report at https://bugs.php.net/bug.php?id=65150&edit=1
ID: 65150
User updated by:mike at silverorange dot com
Reported by:mike at silverorange dot com
Summary:DateTime subclasses expose extra properties
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: CentOS or RHEL
PHP Version:5.3.26
Block user comment: N
Private report: N
New Comment:
The suggested design patterns are not appropriate in this instance because my
object should be an instanceof DateTime. There is no common interface for
DateTime
that allows a proxy object.
The new DateTimeInterface in PHP 5.5 does not contain all the methods of
DateTime.
Previous Comments:
[2013-06-28 18:55:35] mike at silverorange dot com
The properties are not exposed on regular DateTime objects, only on subclasses.
The exposed properties are also read-only which is unintuitive for PHP userland
developers.
[2013-06-28 17:30:13] a...@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
The properties are exposed intentionally, so that's ok. To achieve teh goal
you've
described the proper way were to use an appropriate design pattern, maybe
Facade
or Proxy.
[2013-06-27 21:04:03] mike at silverorange dot com
Description:
I expected the DateTime class properties to be private or at least protected so
users of my subclass don't get internals exposed.
See also https://bugs.php.net/bug.php?id=49382
Test script:
---
class MyDate extends DateTime
{
public $extra = '';
}
$d = new MyDate('2013-01-01', new DateTimeZone('UTC'));
var_dump($d);
Expected result:
class MyDate#1 (4) {
public $extra =>
string(0) ""
}
Actual result:
--
class MyDate#1 (4) {
public $extra =>
string(0) ""
public $date =>
string(19) "2013-01-01 00:00:00"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65150&edit=1
#46024 [NEW]: stream_select doesn't return the correct number
From: mike at silverorange dot com Operating system: linux PHP version: 5.2.6 PHP Bug Type: Streams related Bug description: stream_select doesn't return the correct number Description: The stream_select function should return the number of streams ready in the read and write arrays. Sometimes it does and sometimes it doesn't. Reproduce code: --- http://labs.silverorange.com/files/stream-select-bug/ Expected result: selecting ... got 2 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) selecting ... got 2 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) Actual result: -- selecting ... got 2 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) selecting ... got 1 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) -- Edit bug report at http://bugs.php.net/?id=46024&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46024&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46024&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46024&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46024&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46024&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46024&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46024&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46024&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46024&r=support Expected behavior:http://bugs.php.net/fix.php?id=46024&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46024&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46024&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46024&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46024&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46024&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46024&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46024&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46024&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46024&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46024&r=mysqlcfg
#44882 [NoF->Opn]: SOAP extension object decoding bug
ID: 44882
User updated by: mike at silverorange dot com
Reported By: mike at silverorange dot com
-Status: No Feedback
+Status: Open
Bug Type: SOAP related
Operating System: *
PHP Version: 5.2.5
New Comment:
Reopening bug since feedback indicates the bug still exists in the
posted snapshot.
Previous Comments:
[2008-08-19 02:02:22] michael dot tibben at stomp dot com dot au
The above testcase fails in the 6 Aug 08 snapshot, but works correctly
in php 5.2.20
Please reopen this bug.
[2008-07-29 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-07-21 20:37:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-06-23 15:23:14] anomie at users dot sf dot net
Here is a test case that illustrates the bug, using the same technique
the ext/soap test cases in the PHP distribution use. Please excuse the
big block-o-base64, the namespace URIs in the XML were apparently
triggering your spam filter.
https://www.paypal.com/wsdl/PayPalSvc.wsdl";);
var_dump($client->GetExpressCheckoutDetails(array('GetExpressCheckoutDetailsRequest'=>array('Version'=>50.0,'Token'=>'dummy';
?>
----------------
[2008-05-01 18:02:29] mike at silverorange dot com
Description:
When decoding a SOAP response into zvals, the decoder sometimes gets
confused decoding objects. We noticed this using the PayPal Express
Checkout SOAP API.
For one request type, the returned XML was correct; however, the
decoded PHP objects that were returned were incorrect. One value that
should have been a string was a string reference and an object that
should have been an object was as string.
Upon further investigation, we found other users had been experiencing
this specific problem using PayPal's SOAP API with PHP since PHP 5.2.2.
After a bit of CVS research, it seems the bug was introduced in
1.103.2.21.2.27 in soap_encoding.c to fix bug #37013.
The patch at
http://labs.silverorange.com/files/php-patches/soap-object-reference-bug-20080501.patch
works around the bug for our needs, but it does not fix the underlying
problem and probably reintroduces #37013.
Reproduce code:
---
I can't provide a runnable test case unless you have PayPal developer
API credentials. If so, you can run the unit tests in the package at:
http://labs.silverorange.com/files/Payment_PayPal_Soap/Payment_PayPal_Soap-0.0.4.tgz
The second test will fail if the bug is present and pass if the bug is
fixed.
I've attached a var_dump of broken an working SOAP results to
illustrate the broken 'PayerInfo' element parsing.
Expected result:
object(stdClass)#114 (6) {
["Timestamp"]=>
string(20) "2008-05-01T17:41:45Z"
["Ack"]=>
string(7) "Success"
["CorrelationID"]=>
string(13) "9d6aa8c0309df"
["Version"]=>
string(8) "1.00"
["Build"]=>
string(6) "548868"
["GetExpressCheckoutDetailsResponseDetails"]=>
object(stdClass)#113 (2) {
["Token"]=>
string(20) "EC-6AU15743MX2745842"
["PayerInfo"]=>
object(stdClass)#112 (6) {
["Payer"]=>
string(0) ""
["PayerID"]=>
string(0) ""
["PayerStatus"]=>
string(10) "unverified"
["PayerName"]=>
object(stdClass)#110 (5) {
["Salutation"]=>
string(0) ""
["FirstName"]=>
string(0) ""
["MiddleName"]=>
string(0) ""
["LastName"]=>
string(0) ""
["Suffix"]=>
string(0) ""
}
["PayerBusiness"]=>
string(0) ""
["Address"]=>
object(stdClass)#111 (9) {
["Name"]=>
string(0) ""
["Street1"]=>
string(0) ""
["
#46024 [Fbk->Opn]: stream_select doesn't return the correct number
ID: 46024 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com -Status: Feedback +Status: Open Bug Type: Streams related Operating System: linux PHP Version: 5.2.6 New Comment: The test also fails on the provided snapshot. Previous Comments: [2008-09-08 18:58:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-09-08 14:33:47] mike at silverorange dot com Description: The stream_select function should return the number of streams ready in the read and write arrays. Sometimes it does and sometimes it doesn't. Reproduce code: --- http://labs.silverorange.com/files/stream-select-bug/ Expected result: selecting ... got 2 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) selecting ... got 2 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) Actual result: -- selecting ... got 2 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) selecting ... got 1 Array ( [0] => Resource id #5 ) Array ( [0] => Resource id #6 ) -- Edit this bug report at http://bugs.php.net/?id=46024&edit=1
#44882 [Opn]: SOAP extension object decoding bug
ID: 44882
User updated by: mike at silverorange dot com
Reported By: mike at silverorange dot com
Status: Open
Bug Type: SOAP related
Operating System: *
PHP Version: 5.2.5
New Comment:
I've moved the test provided by anomie into a phpt file at
http://labs.silverorange.com/files/php-bug44882/. The WSDL file is not
included locally as it is the copyrighted work of PayPal.
The test passes using the associated patch but fails against the latest
snapshot (5.2-200810011830).
What else is needed to get this bug fixed?
Previous Comments:
[2008-09-08 14:55:29] mike at silverorange dot com
Reopening bug since feedback indicates the bug still exists in the
posted snapshot.
[2008-08-19 02:02:22] michael dot tibben at stomp dot com dot au
The above testcase fails in the 6 Aug 08 snapshot, but works correctly
in php 5.2.20
Please reopen this bug.
[2008-07-29 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-07-21 20:37:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-06-23 15:23:14] anomie at users dot sf dot net
Here is a test case that illustrates the bug, using the same technique
the ext/soap test cases in the PHP distribution use. Please excuse the
big block-o-base64, the namespace URIs in the XML were apparently
triggering your spam filter.
https://www.paypal.com/wsdl/PayPalSvc.wsdl";);
var_dump($client->GetExpressCheckoutDetails(array('GetExpressCheckoutDetailsRequest'=>array('Version'=>50.0,'Token'=>'dummy';
?>
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/44882
--
Edit this bug report at http://bugs.php.net/?id=44882&edit=1
#44706 [Com]: Segfault after sending PayPal SOAP request
ID: 44706 Comment by: mike at silverorange dot com Reported By: test1 at boxaroo dot com Status: No Feedback Bug Type: SOAP related Operating System: at least Linux and Mac PHP Version: 5.2.5 New Comment: I can confirm this segmentation fault still occurs using the 5.2-200810011830 snapshot. Please reopen this bug. It's probably related to #44882 because on a patched version of PHP, it doesn't segfault. Previous Comments: [2008-08-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-08-12 16:19:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-05-26 08:39:38] jasper at flyingfish dot nl Hi, We are experiencing the same problem on PHP 5.2.6 on Gentoo. This is a real problem for us. Regards, Jasper [2008-04-12 00:52:09] test1 at boxaroo dot com Description: I get a segault when talking to PayPal via SOAP. It seems like the segfault happens AFTER the Soap call has happened, because I can usually dump the results to the screen just before the crash. This happens on a Mac system with PHP 5.2.4 and a Linux system with 5.2.5. I have tried 3 different ways of talking to PayPal; one using their SDK, one using straight SOAP code I wrote, and one using a SOAP wrapper library I found. All crash the same way. I use SOAP for tons of other things (eBay, for instance) without issues. Reproduce code: --- http://img1.boxaroo.com/images/php_soap_segv.txt And, BTW, you do *not* need to put in your PayPal info (I have mine replaced with '---'). It still crashes in the same way whether it accepts your creds or not. Expected result: Should just be a dump of the return; instead you should see the segfault. Actual result: -- Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x2a26b9e5 0x0028ef3e in zend_objects_store_del_ref_by_handle () (gdb) bt #0 0x0028ef3e in zend_objects_store_del_ref_by_handle () #1 0x0028f0b1 in zend_objects_store_del_ref () #2 0x00264ce7 in _zval_ptr_dtor () #3 0x0027bf90 in zend_hash_destroy () #4 0x0028bb22 in zend_object_std_dtor () #5 0x0028bb4a in zend_objects_free_object_storage () #6 0x0028f097 in zend_objects_store_del_ref_by_handle () #7 0x0028f0b1 in zend_objects_store_del_ref () #8 0x00264ce7 in _zval_ptr_dtor () #9 0x0027bf90 in zend_hash_destroy () #10 0x0028bb22 in zend_object_std_dtor () #11 0x0028bb4a in zend_objects_free_object_storage () #12 0x0028f097 in zend_objects_store_del_ref_by_handle () #13 0x0028f0b1 in zend_objects_store_del_ref () #14 0x00264ce7 in _zval_ptr_dtor () #15 0x0027c12a in zend_hash_apply_deleter () #16 0x0027c47c in zend_hash_reverse_apply () #17 0x00263fba in shutdown_destructors () #18 0x00272541 in zend_call_destructors () #19 0x0022dee3 in php_request_shutdown () #20 0x0030243a in main () -- Edit this bug report at http://bugs.php.net/?id=44706&edit=1
#44882 [Fbk->Opn]: SOAP extension object decoding bug
ID: 44882
User updated by: mike at silverorange dot com
Reported By: mike at silverorange dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: *
PHP Version: 5.2.5
New Comment:
The test still fails using the 5.2-200810211030 snapshot.
Previous Comments:
[2008-10-21 11:35:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-10-01 20:27:38] mike at silverorange dot com
I've moved the test provided by anomie into a phpt file at
http://labs.silverorange.com/files/php-bug44882/. The WSDL file is not
included locally as it is the copyrighted work of PayPal.
The test passes using the associated patch but fails against the latest
snapshot (5.2-200810011830).
What else is needed to get this bug fixed?
[2008-06-23 15:23:14] anomie at users dot sf dot net
Here is a test case that illustrates the bug, using the same technique
the ext/soap test cases in the PHP distribution use. Please excuse the
big block-o-base64, the namespace URIs in the XML were apparently
triggering your spam filter.
https://www.paypal.com/wsdl/PayPalSvc.wsdl";);
var_dump($client->GetExpressCheckoutDetails(array('GetExpressCheckoutDetailsRequest'=>array('Version'=>50.0,'Token'=>'dummy';
?>
----------------
[2008-05-01 18:02:29] mike at silverorange dot com
Description:
When decoding a SOAP response into zvals, the decoder sometimes gets
confused decoding objects. We noticed this using the PayPal Express
Checkout SOAP API.
For one request type, the returned XML was correct; however, the
decoded PHP objects that were returned were incorrect. One value that
should have been a string was a string reference and an object that
should have been an object was as string.
Upon further investigation, we found other users had been experiencing
this specific problem using PayPal's SOAP API with PHP since PHP 5.2.2.
After a bit of CVS research, it seems the bug was introduced in
1.103.2.21.2.27 in soap_encoding.c to fix bug #37013.
The patch at
http://labs.silverorange.com/files/php-patches/soap-object-reference-bug-20080501.patch
works around the bug for our needs, but it does not fix the underlying
problem and probably reintroduces #37013.
Reproduce code:
---
I can't provide a runnable test case unless you have PayPal developer
API credentials. If so, you can run the unit tests in the package at:
http://labs.silverorange.com/files/Payment_PayPal_Soap/Payment_PayPal_Soap-0.0.4.tgz
The second test will fail if the bug is present and pass if the bug is
fixed.
I've attached a var_dump of broken an working SOAP results to
illustrate the broken 'PayerInfo' element parsing.
Expected result:
object(stdClass)#114 (6) {
["Timestamp"]=>
string(20) "2008-05-01T17:41:45Z"
["Ack"]=>
string(7) "Success"
["CorrelationID"]=>
string(13) "9d6aa8c0309df"
["Version"]=>
string(8) "1.00"
["Build"]=>
string(6) "548868"
["GetExpressCheckoutDetailsResponseDetails"]=>
object(stdClass)#113 (2) {
["Token"]=>
string(20) "EC-6AU15743MX2745842"
["PayerInfo"]=>
object(stdClass)#112 (6) {
["Payer"]=>
string(0) ""
["PayerID"]=>
string(0) ""
["PayerStatus"]=>
string(10) "unverified"
["PayerName"]=>
object(stdClass)#110 (5) {
["Salutation"]=>
string(0) ""
["FirstName"]=>
string(0) ""
["MiddleName"]=>
string(0) ""
["LastName"]=>
string(0) ""
["Suffix"]=>
string(0) ""
}
["PayerBusiness"]=>
string(0) ""
["Address"]=>
object(stdClass)#111 (9) {
["Name"]=>
string(0) ""
["Street1"]=>
string(0) ""
["Street2"]=>
string(0) ""
["CityName"]=>
string(0) ""
["StateOrProvince"]=>
string(0) ""
["CountryName"]=>
string(0) ""
#44706 [Com]: Segfault after sending PayPal SOAP request
ID: 44706 Comment by: mike at silverorange dot com Reported By: test1 at boxaroo dot com Status: No Feedback Bug Type: SOAP related Operating System: at least Linux and Mac PHP Version: 5.2.5 New Comment: I can confirm this segmentation fault still occurs using the 5.2-200810211030 snapshot. Please reopen this bug. It's probably related to #44882 because on a patched version of PHP, it doesn't segfault. Previous Comments: [2008-10-06 15:32:49] mike at silverorange dot com I can confirm this segmentation fault still occurs using the 5.2-200810011830 snapshot. Please reopen this bug. It's probably related to #44882 because on a patched version of PHP, it doesn't segfault. [2008-08-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-08-12 16:19:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-05-26 08:39:38] jasper at flyingfish dot nl Hi, We are experiencing the same problem on PHP 5.2.6 on Gentoo. This is a real problem for us. Regards, Jasper [2008-04-12 00:52:09] test1 at boxaroo dot com Description: I get a segault when talking to PayPal via SOAP. It seems like the segfault happens AFTER the Soap call has happened, because I can usually dump the results to the screen just before the crash. This happens on a Mac system with PHP 5.2.4 and a Linux system with 5.2.5. I have tried 3 different ways of talking to PayPal; one using their SDK, one using straight SOAP code I wrote, and one using a SOAP wrapper library I found. All crash the same way. I use SOAP for tons of other things (eBay, for instance) without issues. Reproduce code: --- http://img1.boxaroo.com/images/php_soap_segv.txt And, BTW, you do *not* need to put in your PayPal info (I have mine replaced with '---'). It still crashes in the same way whether it accepts your creds or not. Expected result: Should just be a dump of the return; instead you should see the segfault. Actual result: -- Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x2a26b9e5 0x0028ef3e in zend_objects_store_del_ref_by_handle () (gdb) bt #0 0x0028ef3e in zend_objects_store_del_ref_by_handle () #1 0x0028f0b1 in zend_objects_store_del_ref () #2 0x00264ce7 in _zval_ptr_dtor () #3 0x0027bf90 in zend_hash_destroy () #4 0x0028bb22 in zend_object_std_dtor () #5 0x0028bb4a in zend_objects_free_object_storage () #6 0x0028f097 in zend_objects_store_del_ref_by_handle () #7 0x0028f0b1 in zend_objects_store_del_ref () #8 0x00264ce7 in _zval_ptr_dtor () #9 0x0027bf90 in zend_hash_destroy () #10 0x0028bb22 in zend_object_std_dtor () #11 0x0028bb4a in zend_objects_free_object_storage () #12 0x0028f097 in zend_objects_store_del_ref_by_handle () #13 0x0028f0b1 in zend_objects_store_del_ref () #14 0x00264ce7 in _zval_ptr_dtor () #15 0x0027c12a in zend_hash_apply_deleter () #16 0x0027c47c in zend_hash_reverse_apply () #17 0x00263fba in shutdown_destructors () #18 0x00272541 in zend_call_destructors () #19 0x0022dee3 in php_request_shutdown () #20 0x0030243a in main () -- Edit this bug report at http://bugs.php.net/?id=44706&edit=1
[PHP-BUG] Bug #53328 [NEW]: stream_flush error does not cause copy to return false
From: Operating system: Linux PHP version: 5.2.14 Package: Streams related Bug Type: Bug Bug description:stream_flush error does not cause copy to return false Description: In a custom stream wrapper if stream_flush() returns false as the documentation says it may, parent copy operations do not return false. Test script: --- http://labs.silverorange.com/files/php-stream-wrapper/test.phps http://labs.silverorange.com/files/php-stream-wrapper/test.txt Expected result: copy should return false. Actual result: -- copy returns true. -- Edit bug report at http://bugs.php.net/bug.php?id=53328&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53328&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53328&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53328&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53328&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53328&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53328&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53328&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53328&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53328&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53328&r=support Expected behavior: http://bugs.php.net/fix.php?id=53328&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53328&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53328&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53328&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53328&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53328&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53328&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53328&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53328&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53328&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53328&r=mysqlcfg
Bug #53328 [Opn]: stream_flush error does not cause copy to return false
Edit report at http://bugs.php.net/bug.php?id=53328&edit=1 ID: 53328 User updated by:mike at silverorange dot com Reported by:mike at silverorange dot com Summary:stream_flush error does not cause copy to return false Status: Open Type: Bug Package:Streams related Operating System: Linux -PHP Version:5.2.14 +PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Till, thanks for making the phpt file. I tested using the phpt and the raw PHP file, and both fail as described in the original bug report. This is using php 5.3.3 as provided by Ubuntu. I don't see the directory error you describe. Previous Comments: [2010-11-17 15:43:14] t...@php.net Hey Mike, I wanted to write a test case but I fail to reproduce this on 5.3.2 so far. E.g., I wrapped your code into a phpt, all I get is: Warning: copy(): The second argument to copy() function cannot be a directory in /home/till/test/bug53328.php on line 60 bool(false) [ On a sidenote, I don't get this error message either. 'foo' is not a directory, but maybe this means that we have to implement more in the example wrapper for it to work, or this is another bug in the streamwrapper?] Anyway, aside from the weird error message it seems to work indeed on 5.3.2. Here is your code wrapped in a phpt: http://friendpaste.com/7Id22SbWNEBnwLhi9FnSTu Execute with: pear run-tests bug53328.phpt ---- [2010-11-17 06:48:23] mike at silverorange dot com Description: In a custom stream wrapper if stream_flush() returns false as the documentation says it may, parent copy operations do not return false. Test script: --- http://labs.silverorange.com/files/php-stream-wrapper/test.phps http://labs.silverorange.com/files/php-stream-wrapper/test.txt Expected result: copy should return false. Actual result: -- copy returns true. -- Edit this bug report at http://bugs.php.net/bug.php?id=53328&edit=1
Bug #53328 [Opn]: copy() returns false even if closing the destination file fails
Edit report at http://bugs.php.net/bug.php?id=53328&edit=1 ID: 53328 User updated by:mike at silverorange dot com Reported by:mike at silverorange dot com Summary:copy() returns false even if closing the destination file fails Status: Open Type: Bug Package:Streams related Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: fflush does correctly return false, but the point of stream wrappers is to be able to use the stream functions as I normally would. I normally use copy to copy a stream rather than an fopen, fread, fwrite, fflush, fclose loop. Because of this bug, there's no way to properly detect errors when copying to custom streams. In practice, this results in data loss. I'm fine with the fix going in trunk as afaik php 5.2.x is reaching end of life and this is not a security issue. Previous Comments: [2010-11-18 07:52:21] cataphr...@php.net The function you should be testing would be fflush, not copy. fflush does actually return false. The flush operation is called for collaterals when closing the file. copy() should probably return false if closing, at least, the destination file fails, but it's a risky move because in PHP, for better or worse, the return value of php_stream_close and friends is almost always ignored. We'd be giving significance to something that's almost always ignored. Maybe for trunk... ---- [2010-11-17 16:36:47] mike at silverorange dot com Till, thanks for making the phpt file. I tested using the phpt and the raw PHP file, and both fail as described in the original bug report. This is using php 5.3.3 as provided by Ubuntu. I don't see the directory error you describe. [2010-11-17 15:43:14] t...@php.net Hey Mike, I wanted to write a test case but I fail to reproduce this on 5.3.2 so far. E.g., I wrapped your code into a phpt, all I get is: Warning: copy(): The second argument to copy() function cannot be a directory in /home/till/test/bug53328.php on line 60 bool(false) [ On a sidenote, I don't get this error message either. 'foo' is not a directory, but maybe this means that we have to implement more in the example wrapper for it to work, or this is another bug in the streamwrapper?] Anyway, aside from the weird error message it seems to work indeed on 5.3.2. Here is your code wrapped in a phpt: http://friendpaste.com/7Id22SbWNEBnwLhi9FnSTu Execute with: pear run-tests bug53328.phpt ------------ [2010-11-17 06:48:23] mike at silverorange dot com Description: In a custom stream wrapper if stream_flush() returns false as the documentation says it may, parent copy operations do not return false. Test script: --- http://labs.silverorange.com/files/php-stream-wrapper/test.phps http://labs.silverorange.com/files/php-stream-wrapper/test.txt Expected result: copy should return false. Actual result: -- copy returns true. -- Edit this bug report at http://bugs.php.net/bug.php?id=53328&edit=1
#44667 [NEW]: proc_open does not handle pipes with the mode 'wb' correctly
From: mike at silverorange dot com
Operating system: Irrelevant
PHP version: 5.2CVS-2008-04-08 (CVS)
PHP Bug Type: Program Execution
Bug description: proc_open does not handle pipes with the mode 'wb' correctly
Description:
proc_open.c checks if the mode parameter != "w" instead of checking the
first character of the mode parameter. This prevents the mode 'wb' from
working properly.
Reproduce code:
---
array('pipe', 'rb'),
1 => array('pipe', 'wb'),
);
$proc = proc_open('cat', $descriptor_spec, $pipes);
fwrite($pipes[0], 'Hello', 5);
fflush($pipes[0]);
fclose($pipes[0]);
$result = fread($pipes[1], 5);
fclose($pipes[1]);
proc_close($proc);
echo "Result is: ", $result, "\n";
?>
Expected result:
Result is: Hello
Actual result:
--
on stderr:
cat: write error: Bad file descriptor
on stdout:
Result is:
--
Edit bug report at http://bugs.php.net/?id=44667&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44667&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44667&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44667&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44667&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44667&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44667&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44667&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44667&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44667&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44667&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44667&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44667&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44667&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44667&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44667&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44667&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44667&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44667&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44667&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44667&r=mysqlcfg
#44857 [NEW]: no property_exists() equivalent for magic properties
From: mike at silverorange dot com Operating system: PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: no property_exists() equivalent for magic properties Description: There is currently no way to determine if a magic __get() property exists. The __isset() function should use 'isset(null) == false' semantics so it cannot be used to reliably check if a magic property exists. I propose a new magic method __property_exists($name) or __propertyExists($name) be created that hooks into the property_exists() function. It would return true iff __get($name) returns any value. -- Edit bug report at http://bugs.php.net/?id=44857&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44857&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44857&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44857&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44857&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44857&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44857&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44857&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44857&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44857&r=support Expected behavior:http://bugs.php.net/fix.php?id=44857&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44857&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44857&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44857&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44857&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44857&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44857&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44857&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44857&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44857&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44857&r=mysqlcfg
#44882 [NEW]: SOAP extension object decoding bug
From: mike at silverorange dot com
Operating system: Irrelevant
PHP version: 5.2.5
PHP Bug Type: SOAP related
Bug description: SOAP extension object decoding bug
Description:
When decoding a SOAP response into zvals, the decoder sometimes gets
confused decoding objects. We noticed this using the PayPal Express
Checkout SOAP API.
For one request type, the returned XML was correct; however, the decoded
PHP objects that were returned were incorrect. One value that should have
been a string was a string reference and an object that should have been an
object was as string.
Upon further investigation, we found other users had been experiencing
this specific problem using PayPal's SOAP API with PHP since PHP 5.2.2.
After a bit of CVS research, it seems the bug was introduced in
1.103.2.21.2.27 in soap_encoding.c to fix bug #37013.
The patch at
http://labs.silverorange.com/files/php-patches/soap-object-reference-bug-20080501.patch
works around the bug for our needs, but it does not fix the underlying
problem and probably reintroduces #37013.
Reproduce code:
---
I can't provide a runnable test case unless you have PayPal developer API
credentials. If so, you can run the unit tests in the package at:
http://labs.silverorange.com/files/Payment_PayPal_Soap/Payment_PayPal_Soap-0.0.4.tgz
The second test will fail if the bug is present and pass if the bug is
fixed.
I've attached a var_dump of broken an working SOAP results to illustrate
the broken 'PayerInfo' element parsing.
Expected result:
object(stdClass)#114 (6) {
["Timestamp"]=>
string(20) "2008-05-01T17:41:45Z"
["Ack"]=>
string(7) "Success"
["CorrelationID"]=>
string(13) "9d6aa8c0309df"
["Version"]=>
string(8) "1.00"
["Build"]=>
string(6) "548868"
["GetExpressCheckoutDetailsResponseDetails"]=>
object(stdClass)#113 (2) {
["Token"]=>
string(20) "EC-6AU15743MX2745842"
["PayerInfo"]=>
object(stdClass)#112 (6) {
["Payer"]=>
string(0) ""
["PayerID"]=>
string(0) ""
["PayerStatus"]=>
string(10) "unverified"
["PayerName"]=>
object(stdClass)#110 (5) {
["Salutation"]=>
string(0) ""
["FirstName"]=>
string(0) ""
["MiddleName"]=>
string(0) ""
["LastName"]=>
string(0) ""
["Suffix"]=>
string(0) ""
}
["PayerBusiness"]=>
string(0) ""
["Address"]=>
object(stdClass)#111 (9) {
["Name"]=>
string(0) ""
["Street1"]=>
string(0) ""
["Street2"]=>
string(0) ""
["CityName"]=>
string(0) ""
["StateOrProvince"]=>
string(0) ""
["CountryName"]=>
string(0) ""
["PostalCode"]=>
string(0) ""
["AddressOwner"]=>
string(6) "PayPal"
["AddressStatus"]=>
string(4) "None"
}
}
}
}
Actual result:
--
object(stdClass)#114 (6) {
["Timestamp"]=>
string(20) "2008-05-01T17:56:31Z"
["Ack"]=>
string(7) "Success"
["CorrelationID"]=>
string(13) "233fdab3c0758"
["Version"]=>
string(8) "1.00"
["Build"]=>
string(6) "548868"
["GetExpressCheckoutDetailsResponseDetails"]=>
object(stdClass)#113 (2) {
["Token"]=>
&string(20) "EC-8JA130819B922424F"
["PayerInfo"]=>
string(20) "EC-8JA130819B922424F"
}
}
--
Edit bug report at http://bugs.php.net/?id=44882&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44882&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44882&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44882&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44882&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44882&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44882&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44882&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44882&r=oldversion
Not develope
#44908 [NEW]: stream_select on pipes returned by proc_open returns streams that are not ready
From: mike at silverorange dot com
Operating system: Windows
PHP version: 5.2.6
PHP Bug Type: Streams related
Bug description: stream_select on pipes returned by proc_open returns streams
that are not ready
Description:
When using stream_select() on pipes returned by proc_open() in Windows,
input streams that are not ready are returned in the modified $read array.
Reproduce code:
---
array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')), $pipes, null, $_ENV);
if ($proc !== false) {
$write = array($pipes[0]);
$read = array($pipes[1], $pipes[2]);
$except = null;
$changed = stream_select($read, $write, $except, null);
if ($changed) {
print_r($read);
print_r($write);
}
proc_close($proc);
}
?>
Expected result:
The read array will be empty and the write array will contain stdin.
Actual result:
--
The read array contains stdin and the write array contains stdout and
stderr. The stdout and stderr streams have no data ready and fread() will
block indefinitely.
--
Edit bug report at http://bugs.php.net/?id=44908&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44908&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44908&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44908&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44908&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44908&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44908&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44908&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44908&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44908&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44908&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44908&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44908&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44908&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44908&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44908&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44908&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44908&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44908&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44908&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44908&r=mysqlcfg
#44908 [Opn]: stream_select on pipes returned by proc_open returns streams that are not ready
ID: 44908
User updated by: mike at silverorange dot com
Reported By: mike at silverorange dot com
Status: Open
Bug Type: Streams related
Operating System: Windows
PHP Version: 5.2.6
New Comment:
Edit:
Actual result:
--
The _write_ array contains stdin and the _read_ array contains stdout
and stderr. The stdout and stderr streams have no data ready and fread()
will block indefinitely.
Previous Comments:
[2008-05-04 08:06:11] mike at silverorange dot com
Description:
When using stream_select() on pipes returned by proc_open() in Windows,
input streams that are not ready are returned in the modified $read
array.
Reproduce code:
---
array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')), $pipes, null, $_ENV);
if ($proc !== false) {
$write = array($pipes[0]);
$read = array($pipes[1], $pipes[2]);
$except = null;
$changed = stream_select($read, $write, $except, null);
if ($changed) {
print_r($read);
print_r($write);
}
proc_close($proc);
}
?>
Expected result:
The read array will be empty and the write array will contain stdin.
Actual result:
--
The read array contains stdin and the write array contains stdout and
stderr. The stdout and stderr streams have no data ready and fread()
will block indefinitely.
--
Edit this bug report at http://bugs.php.net/?id=44908&edit=1
#44908 [Fbk->Opn]: stream_select on pipes returned by proc_open returns streams that are not ready
ID: 44908
User updated by: mike at silverorange dot com
Reported By: mike at silverorange dot com
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: Windows
PHP Version: 5.2.6
Assigned To: fb-req-jani
New Comment:
Jani,
I'm using the MSI install of PHP 5.2.6 (cli) (built Apr 30 2008
16:19:00) on Windows XP Home with Service Pack 2.
Previous Comments:
[2008-05-04 21:50:20] [EMAIL PROTECTED]
Please check the used PHP version. (phpinfo(); usually is the best way)
[2008-05-04 08:08:55] mike at silverorange dot com
Edit:
Actual result:
--
The _write_ array contains stdin and the _read_ array contains stdout
and stderr. The stdout and stderr streams have no data ready and fread()
will block indefinitely.
[2008-05-04 08:06:11] mike at silverorange dot com
Description:
When using stream_select() on pipes returned by proc_open() in Windows,
input streams that are not ready are returned in the modified $read
array.
Reproduce code:
---
array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')), $pipes, null, $_ENV);
if ($proc !== false) {
$write = array($pipes[0]);
$read = array($pipes[1], $pipes[2]);
$except = null;
$changed = stream_select($read, $write, $except, null);
if ($changed) {
print_r($read);
print_r($write);
}
proc_close($proc);
}
?>
Expected result:
The read array will be empty and the write array will contain stdin.
Actual result:
--
The read array contains stdin and the write array contains stdout and
stderr. The stdout and stderr streams have no data ready and fread()
will block indefinitely.
--
Edit this bug report at http://bugs.php.net/?id=44908&edit=1
#38618 [Fbk->Opn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com -Status: Feedback +Status: Open Bug Type: SPL related Operating System: Linux PHP Version: 5.2.3 Assigned To: feedback asked New Comment: I tried changing the scope of the $title property from protected to public and the test case does indeed run correctly. Even so, the test case should still run correctly when the property is protected. Previous Comments: [2007-08-20 10:34:33] [EMAIL PROTECTED] Replace "protected" with "public" and it works fine.. [2007-07-02 15:03:09] mike at silverorange dot com Sorray about that. Try this link: http://labs.silverorange.com/local/solabs/include/recursive-array-iterator.txt [2007-06-28 01:51:27] mike at silverorange dot com This bug still exists in PHP 5.2.3 using the same test script as before. [2006-08-27 22:10:35] mike at silverorange dot com Description: The default implementation of hasChildren() in RecursiveArrayIterator does not work if the recursive array contains object references. If I subclass the RecursiveArrayIterator and re-implement the method exactly as it is in the source code everything is fine. If I use the default implementation, the objects in my array do not get iterated. Inside my re-implemented hasChildren() method if I call parent::hasChildren() it returns 1 when $this->current() is an object. Reproduce code: --- Code to reproduce: http://wiki.silverorange.com/Recursive_Array_Iterator Expected result: Expected output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Actual result: -- Output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
#38618 [Opn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com Status: Open Bug Type: SPL related Operating System: Linux PHP Version: 5.2.3 Assigned To: feedback asked New Comment: I played around with the test case a bit more and it seems that the default RecursiveArrayIterator iterates the public properties of objects within the arrays. For example, if I adda public $foo = 'bar' property to the Fruit class, I get the following (incorrect) output: Default recursive array iteraration: title => apple foo => bar title => orange foo => bar title => banana foo => bar title => grape foo => bar title => peach foo => bar title => strawberry foo => bar title => grapefruit foo => bar Previous Comments: ------------ [2007-08-20 14:05:21] mike at silverorange dot com I tried changing the scope of the $title property from protected to public and the test case does indeed run correctly. Even so, the test case should still run correctly when the property is protected. [2007-08-20 10:34:33] [EMAIL PROTECTED] Replace "protected" with "public" and it works fine.. ------------ [2007-07-02 15:03:09] mike at silverorange dot com Sorray about that. Try this link: http://labs.silverorange.com/local/solabs/include/recursive-array-iterator.txt ------------ [2007-06-28 01:51:27] mike at silverorange dot com This bug still exists in PHP 5.2.3 using the same test script as before. ------------ [2006-08-27 22:10:35] mike at silverorange dot com Description: The default implementation of hasChildren() in RecursiveArrayIterator does not work if the recursive array contains object references. If I subclass the RecursiveArrayIterator and re-implement the method exactly as it is in the source code everything is fine. If I use the default implementation, the objects in my array do not get iterated. Inside my re-implemented hasChildren() method if I call parent::hasChildren() it returns 1 when $this->current() is an object. Reproduce code: --- Code to reproduce: http://wiki.silverorange.com/Recursive_Array_Iterator Expected result: Expected output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Actual result: -- Output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
#41147 [Com]: mb_check_encoding fails to check invalid string
ID: 41147
Comment by: mike at silverorange dot com
Reported By: teracci2002 at yahoo dot co dot jp
Status: Assigned
Bug Type: mbstring related
Operating System: Linux
PHP Version: 5.2.1
Assigned To: hirokawa
New Comment:
0x00, 0xe3 is a valid byte sequence in UTF-8 but by itself is not a
valid UTF-8 string (it's missing two bytes).
The function is documented as checking the validity of a string so it
should return false for this case. If the function is only supposed to
validate byte-streams then the documentation should be fixed.
Previous Comments:
[2007-09-16 08:56:57] [EMAIL PROTECTED]
Sorry for delaying response.
0x00,0x81 is also valid byte sequence in Shift_JIS
because 0x81 is a valid first byte of a double-byte
JIS X 0208 character.
See: http://en.wikipedia.org/wiki/Shift_jis
We cannot decide the byte stream is valid or
invalid because the last byte of byte stream (0x81)
is a valid first byte of double-byte character.
In this case, true (valid) will be returned.
The byte stream including a valid first byte +
a invalid second byte returns false.
For example,
var_dump(mb_check_encoding("\x81\x00", "Shift_JIS"));
returns false (invalid).
It is because 0x81 is valid first byte of a double-byte
JIS X0208 character, but, 0x00 is invalid second byte of
a double-byte JIS X0208 character.
And,
0x00, 0xe3 in UTF-8, it is also
valid byte sequence (a null byte + first byte of
a three-byte UTF-8 character).
See: http://en.wikipedia.org/wiki/UTF-8
[2007-09-04 22:38:26] [EMAIL PROTECTED]
Did you read it Rui? (why do your reports end up as 'Analyzed' all the
time? :)
[2007-09-04 14:55:58] teracci2002 at yahoo dot co dot jp
> 0x00+0xa1 is valid byte sequence in Shift_JIS sequence.
I know it.
But 0x00+0x81 is invalid sequence in Shift_JIS.
Then, why below statement returns "bool(true)" ?
var_dump(mb_check_encoding("\x00\x81", "Shift_JIS"));
Read bug report again, please.
[2007-09-04 14:30:06] [EMAIL PROTECTED]
> No one says 0x00,0xa1 is invalid character in ShiftJIS.
I didn't say that.
0x00+0xa1 is valid byte sequence in Shift_JIS sequence.
A character in Shift_JIS encoding is encoded in either single byte
or double byte.
In this case, the byte stream is reconigzed as two character,
a null byte and a comma character in Katakana(0xa1)
see: http://hp.vector.co.jp/authors/VA013241/misc/shiftjis.html
[2007-08-19 20:10:06] [EMAIL PROTECTED]
Someone disagrees, Rui.. :)
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/41147
--
Edit this bug report at http://bugs.php.net/?id=41147&edit=1
#43089 [NEW]: DOMDocument::loadXML() causes warning not trapped by libxml errors
From: mike at silverorange dot com
Operating system:
PHP version: 5.2.4
PHP Bug Type: DOM XML related
Bug description: DOMDocument::loadXML() causes warning not trapped by libxml
errors
Description:
When libxml_use_internal_errors() is used, DOMDocument::loadXML() still
causes a general PHP warning to be raised when passed an empty string.
If this is by design, the documentation should mention this warning will
be triggered if an empty string is used.
Reproduce code:
---
$errors = libxml_use_internal_errors(true);
$document = new DOMDocument();
var_dump($document->loadXML(''));
libxml_clear_errors();
libxml_use_internal_errors($errors);
Expected result:
bool(false)
Actual result:
--
Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: Empty
string supplied as input
bool(false)
--
Edit bug report at http://bugs.php.net/?id=43089&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43089&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43089&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43089&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43089&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43089&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43089&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43089&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43089&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43089&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43089&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43089&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43089&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43089&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43089&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43089&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43089&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43089&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43089&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43089&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43089&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43089&r=mysqlcfg
#38618 [NEW]: default implementation of hasChildren() in RecursiveArrayIterator does not work
From: mike at silverorange dot com Operating system: Linux PHP version: 5.1.5 PHP Bug Type: SPL related Bug description: default implementation of hasChildren() in RecursiveArrayIterator does not work Description: The default implementation of hasChildren() in RecursiveArrayIterator does not work if the recursive array contains object references. If I subclass the RecursiveArrayIterator and re-implement the method exactly as it is in the source code everything is fine. If I use the default implementation, the objects in my array do not get iterated. Inside my re-implemented hasChildren() method if I call parent::hasChildren() it returns 1 when $this->current() is an object. Reproduce code: --- Code to reproduce: http://wiki.silverorange.com/Recursive_Array_Iterator Expected result: Expected output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Actual result: -- Output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit -- Edit bug report at http://bugs.php.net/?id=38618&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38618&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38618&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38618&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38618&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38618&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38618&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38618&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38618&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38618&r=support Expected behavior:http://bugs.php.net/fix.php?id=38618&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38618&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38618&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38618&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38618&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38618&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38618&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38618&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38618&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38618&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38618&r=mysqlcfg
#37391 [NEW]: PREG_OFFSET_CAPTURE not UTF-8 aware when using u modifier
From: mike at silverorange dot com Operating system: Linux PHP version: 5.1.4 PHP Bug Type: PCRE related Bug description: PREG_OFFSET_CAPTURE not UTF-8 aware when using u modifier Description: When using preg_match_all() with the PREG_OFFSET_CAPTURE flag, the returned match offsets are in octets rather than characters. PCRE is compiled with --enable-utf8 and I am using the u modifier in my regular expression. Reproduce code: --- Expected result: Array ( [0] => Array ( [0] => Array ( [0] => B [1] => 2 ) ) ) Actual result: -- Array ( [0] => Array ( [0] => Array ( [0] => B [1] => 4 ) ) ) -- Edit bug report at http://bugs.php.net/?id=37391&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37391&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37391&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37391&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37391&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37391&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37391&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37391&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37391&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37391&r=support Expected behavior:http://bugs.php.net/fix.php?id=37391&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37391&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37391&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37391&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37391&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37391&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37391&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37391&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37391&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37391&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37391&r=mysqlcfg
#38618 [NoF->Opn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com -Status: No Feedback +Status: Open Bug Type: SPL related Operating System: Linux PHP Version: 5.1.5 New Comment: reopening Previous Comments: [2006-09-05 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-08-28 10:47:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-08-27 22:10:35] mike at silverorange dot com Description: The default implementation of hasChildren() in RecursiveArrayIterator does not work if the recursive array contains object references. If I subclass the RecursiveArrayIterator and re-implement the method exactly as it is in the source code everything is fine. If I use the default implementation, the objects in my array do not get iterated. Inside my re-implemented hasChildren() method if I call parent::hasChildren() it returns 1 when $this->current() is an object. Reproduce code: --- Code to reproduce: http://wiki.silverorange.com/Recursive_Array_Iterator Expected result: Expected output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Actual result: -- Output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
#38618 [Opn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com Status: Open Bug Type: SPL related Operating System: Linux PHP Version: 5.1.5 New Comment: This bug still exists in PHP 5.2.3 using the same test script as before. Previous Comments: [2007-06-28 01:50:26] mike at silverorange dot com reopening [2006-09-05 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-08-28 10:47:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-08-27 22:10:35] mike at silverorange dot com Description: The default implementation of hasChildren() in RecursiveArrayIterator does not work if the recursive array contains object references. If I subclass the RecursiveArrayIterator and re-implement the method exactly as it is in the source code everything is fine. If I use the default implementation, the objects in my array do not get iterated. Inside my re-implemented hasChildren() method if I call parent::hasChildren() it returns 1 when $this->current() is an object. Reproduce code: --- Code to reproduce: http://wiki.silverorange.com/Recursive_Array_Iterator Expected result: Expected output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Actual result: -- Output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
#38618 [Fbk->Opn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com -Status: Feedback +Status: Open Bug Type: SPL related Operating System: Linux PHP Version: 5.1.5 New Comment: Try this URL: http://labs.silverorange.com/local/solabs/include/recursive-array-iterator.php Previous Comments: [2007-06-28 06:05:37] [EMAIL PROTECTED] telnet wiki.silverorange.com 80 telnet: wiki.silverorange.com: Name or service not known wiki.silverorange.com: Unknown host [2007-06-28 01:51:27] mike at silverorange dot com This bug still exists in PHP 5.2.3 using the same test script as before. [2007-06-28 01:50:26] mike at silverorange dot com reopening [2006-09-05 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-08-28 10:47:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/38618 -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
#38618 [Fbk->Opn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 User updated by: mike at silverorange dot com Reported By: mike at silverorange dot com -Status: Feedback +Status: Open Bug Type: SPL related Operating System: Linux PHP Version: 5.2.3 New Comment: Sorray about that. Try this link: http://labs.silverorange.com/local/solabs/include/recursive-array-iterator.txt Previous Comments: [2007-06-29 12:10:18] [EMAIL PROTECTED] I'm more interested in the reproduce case than in its output. [2007-06-28 16:26:15] mike at silverorange dot com Try this URL: http://labs.silverorange.com/local/solabs/include/recursive-array-iterator.php [2007-06-28 06:05:37] [EMAIL PROTECTED] telnet wiki.silverorange.com 80 telnet: wiki.silverorange.com: Name or service not known wiki.silverorange.com: Unknown host [2007-06-28 01:51:27] mike at silverorange dot com This bug still exists in PHP 5.2.3 using the same test script as before. [2006-08-27 22:10:35] mike at silverorange dot com Description: The default implementation of hasChildren() in RecursiveArrayIterator does not work if the recursive array contains object references. If I subclass the RecursiveArrayIterator and re-implement the method exactly as it is in the source code everything is fine. If I use the default implementation, the objects in my array do not get iterated. Inside my re-implemented hasChildren() method if I call parent::hasChildren() it returns 1 when $this->current() is an object. Reproduce code: --- Code to reproduce: http://wiki.silverorange.com/Recursive_Array_Iterator Expected result: Expected output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Actual result: -- Output from reproduce code: Default recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit Default recursive array iteraration: Reimplemented hasChildren() recursive array iteraration: 1 => apple 2 => orange 3 => banana 1 => grape 2 => peach 3 => strawberry 4 => grapefruit -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
