Req #60577 [Opn->Ver]: count(new EmptyIterator) returns 1
Edit report at https://bugs.php.net/bug.php?id=60577&edit=1 ID: 60577 Updated by: le...@php.net Reported by:adam at sixohthree dot com Summary:count(new EmptyIterator) returns 1 -Status: Open +Status: Verified Type: Feature/Change Request Package:SPL related PHP Version:5.4SVN-2011-12-20 (SVN) Block user comment: N Private report: N New Comment: I confirmed this for versions 5.1.0 - 5.5.3. Previous Comments: [2011-12-20 20:17:50] adam at sixohthree dot com Description: As an object that simulates a list of zero items, count(new EmptyIterator) should return zero. Test script: --- https://bugs.php.net/bug.php?id=60577&edit=1
Bug #52560 [Asn->Nab]: FilterIterator errantly returns null for first element
Edit report at https://bugs.php.net/bug.php?id=52560&edit=1 ID: 52560 Updated by: le...@php.net Reported by:tobias382 at gmail dot com Summary:FilterIterator errantly returns null for first element -Status: Assigned +Status: Not a bug Type: Bug Package:SPL related Operating System: Ubuntu 10.04 PHP Version:5.3SVN-2010-08-07 (snap) -Assigned To:colder +Assigned To:levim Block user comment: N Private report: N New Comment: This is simply a common misunderstanding. Iterators need to be rewound before use. Whether that was a good design or not is debatable, but nonetheless this is not a bug. Previous Comments: [2010-08-07 04:49:28] tobias382 at gmail dot com Small amendment: $iterator->rewind() should be $this->rewind() in the overridden constructor in the test script. [2010-08-07 04:40:26] tobias382 at gmail dot com Description: Even when a FilterIterator subclass accepts all elements, it returns NULL for the first element in the original array. There are a few methods to correct this behavior, noted in the attached test script. Test script: --- rewind(); } */ // Should cause all elements to be accepted public function accept() { return true; } /* // Another way to force this class to produce expected behavior below public function current() { return $this->getInnerIterator()->current(); } */ } $array = array(1, 2); /* // What should happen in subsequent blocks $iterator1 = new ArrayIterator($array); var_dump($iterator1->current()); // int(1) $iterator1->next(); var_dump($iterator1->current()); // int(2) $iterator1->next(); var_dump($iterator1->current()); // NULL */ // The problem $iterator2 = new FooIterator(new ArrayIterator($array)); var_dump($iterator2->current()); // NULL <-- this should be int(1) $iterator2->next(); var_dump($iterator2->current()); // int(2) $iterator2->next(); var_dump($iterator2->current()); // NULL // Exhibits correct behavior with no changes to FooIterator $iterator3 = new FooIterator(new ArrayIterator($array)); $iterator3->rewind(); // This line shouldn't be needed, but is to force expected behavior var_dump($iterator3->current()); // int(1) $iterator3->next(); var_dump($iterator3->current()); // int(2) $iterator3->next(); var_dump($iterator3->current()); // NULL Expected result: int(1) int(2) NULL int(1) int(2) NULL Actual result: -- NULL int(2) NULL int(1) int(2) NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=52560&edit=1
Bug #65629 [Opn->Ver]: SplObjectsStorage::detach() rewinds internal pointer
Edit report at https://bugs.php.net/bug.php?id=65629&edit=1 ID: 65629 Updated by: le...@php.net Reported by:alan dot bem at gmail dot com Summary:SplObjectsStorage::detach() rewinds internal pointer -Status: Open +Status: Verified Type: Bug Package:SPL related PHP Version:Irrelevant -Assigned To: +Assigned To:levim Block user comment: N Private report: N New Comment: Regardless of whether this is a bug, in general modifying a structure during iteration has undefined behavior. I will look a bit into this and see what might be done. Previous Comments: [2013-09-07 03:14:18] alan dot bem at gmail dot com Description: It seems that SplObjectsStorage::detach() internally rewinds its array pointer. PHP versions from 5.1.0 to 5.5.3 are affected. Test script: --- // To see this live, go to: http://3v4l.org/MAELj val = $val; } } $storage = new SplObjectStorage; for($i = 1; $i <= 10; $i++) { $storage->attach(new A($i)); } $iterations = 0; $storage->rewind(); while ($storage->valid()) { $iterations++; $object = $storage->current(); echo 'Iteration #' . $iterations . ' with object A(' . $object->val . ')'; $storage->next(); if($iterations === 2 || $iterations === 8) { $storage->detach($object); echo ' - deleted Object A(' . $object->val . ') '; } echo PHP_EOL; } echo 'Number of iterations: ' . $iterations . PHP_EOL; Expected result: Iteration #1 with object A(1) Iteration #2 with object A(2) - deleted Object A(2) Iteration #3 with object A(3) Iteration #4 with object A(4) Iteration #5 with object A(5) Iteration #6 with object A(6) Iteration #7 with object A(7) - deleted Object A(7) Iteration #8 with object A(8) Iteration #9 with object A(9) Iteration #10 with object A(10) Number of iterations: 10 Actual result: -- Iteration #1 with object A(1) Iteration #2 with object A(2) - deleted Object A(2) Iteration #3 with object A(1) Iteration #4 with object A(3) Iteration #5 with object A(4) Iteration #6 with object A(5) Iteration #7 with object A(6) Iteration #8 with object A(7) - deleted Object A(7) Iteration #9 with object A(1) Iteration #10 with object A(3) Iteration #11 with object A(4) Iteration #12 with object A(5) Iteration #13 with object A(6) Iteration #14 with object A(8) Iteration #15 with object A(9) Iteration #16 with object A(10) Number of iterations: 16 -- Edit this bug report at https://bugs.php.net/bug.php?id=65629&edit=1
Bug #63917 [Opn->Dup]: SplObjectStorage: Iteration of all the objects is not possible after detach()
Edit report at https://bugs.php.net/bug.php?id=63917&edit=1 ID: 63917 Updated by: le...@php.net Reported by:LastDragon at yandex dot ru Summary:SplObjectStorage: Iteration of all the objects is not possible after detach() -Status: Open +Status: Duplicate Type: Bug Package:SPL related Operating System: all PHP Version:5.4.10 Block user comment: N Private report: N New Comment: This is duplicate of bug #65629 (https://bugs.php.net/bug.php?id=65629). Previous Comments: [2013-01-09 15:18:22] ashn...@php.net The following patch has been added/updated: Patch Name: bug63917.phpt Revision: 1357744702 URL: https://bugs.php.net/patch-display.php?bug=63917&patch=bug63917.phpt&revision=1357744702 [2013-01-09 06:05:45] LastDragon at yandex dot ru > Are the "Expected" and "Actual" blocks reversed on this initial report? Yes. Sorry. Unfortunately I cannot edit this blocks :( [2013-01-08 21:05:06] ashn...@php.net Are the "Expected" and "Actual" blocks reversed on this initial report? I came searching for an SplObjectStorage bug where attempting to foreach() it and detach all its members was failing to detach the final member. This bug report looks like it reports exactly that, if you switch the Expected and Actual blocks. In my case, a foreach() around one SplObjectStorage object that performs a detach() per member is finishing the foreach() loop while leaving one member still attached. I can do a second foreach() on the SplObjectStorage object, and this time it does see the remaining one member and detaches it successfully. I suspect, as this bug report seems to specifically say, that the detach() operation in the foreach() is causing an off-by-one error or is implicitly calling one of the Iterator methods in a way that throws off the foreach()'s Iterator steps. [2013-01-06 11:25:18] LastDragon at yandex dot ru Description: Iteration of all the objects is not possible after the detach method was called. Test script: --- attach(new StdClass); $s->attach(new StdClass); $s->attach(new StdClass); $s->attach(new StdClass); var_dump($s->count()); foreach ($s as $v) { var_dump($v); $s->detach($v); } var_dump($s->count()); Expected result: int(4) object(stdClass)#2 (0) { } object(stdClass)#4 (0) { } object(stdClass)#5 (0) { } int(1) Actual result: -- int(4) object(stdClass)#2 (0) { } object(stdClass)#3 (0) { } object(stdClass)#4 (0) { } object(stdClass)#5 (0) { } int(0) -- Edit this bug report at https://bugs.php.net/bug.php?id=63917&edit=1
Req #49967 [Asn->Csd]: Custom iteration cannot return keys other than ints or strings
Edit report at https://bugs.php.net/bug.php?id=49967&edit=1 ID: 49967 Updated by: le...@php.net Reported by:an0nym at narod dot ru Summary:Custom iteration cannot return keys other than ints or strings -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:5.3.0 Assigned To:colder Block user comment: N Private report: N New Comment: As of PHP 5.5, this is now fixed. Previous Comments: [2009-11-11 12:13:28] col...@php.net This is indeed a limitation of the iteration process itself, nothing specific to splobjectstorage. [2009-10-23 10:27:31] an0nym at narod dot ru Ah, it seems that foreach can't handle anything non-scalar as a key. What a pity. I think this should be changed in the future, because it limits the use of Iterators. For instance, I can't use something like: $data) { var_dump ($object, $data); } ?> [2009-10-23 10:08:10] an0nym at narod dot ru Description: Iteration over SplObjectStorage returns unexpected results: internal index => associated object instead of object => associated data. Reproduce code: --- $data) { var_dump ($object, $data); } ?> Expected result: object(stdClass)#2 (0) { } string(1) "a" object(stdClass)#3 (0) { } string(1) "b" Actual result: -- int(0) object(stdClass)#2 (0) { } int(1) object(stdClass)#2 (0) { } -- Edit this bug report at https://bugs.php.net/bug.php?id=49967&edit=1
Bug #63507 [Opn->Csd]: IteratorIterator inheritance problems
Edit report at https://bugs.php.net/bug.php?id=63507&edit=1 ID: 63507 Updated by: le...@php.net Reported by:le...@php.net Summary:IteratorIterator inheritance problems -Status: Open +Status: Closed Type: Bug Package:SPL related PHP Version:Irrelevant -Assigned To: +Assigned To:levim Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. I seem to have tested the wrong things, somehow. Silly mistake. Previous Comments: [2012-11-13 22:12:23] le...@php.net Description: IteratorIterator has a method `seek` that matches the signature for implementing SeekableIterator, but it doesn't implement the interface. Also, subclasses of IteratorIterator do not inherit the seek method. This breaks the rules for inheritance. I'm not sure how to propose fixing it at this point. This should have been caught before being released. Like much of the SPL, this was not properly thought out and tested. Test script: --- $iterator = new IteratorIterator( new EmptyIterator() ); var_dump($iterator instanceof SeekableIterator); var_dump(method_exists($iterator, 'seek'); $iterator = new NoRewindIterator( new EmptyIterator() ); var_dump(method_exists($iterator, 'seek'); Expected result: bool(true); bool(true); bool(true); Actual result: -- bool(false); bool(true); bool(false); -- Edit this bug report at https://bugs.php.net/bug.php?id=63507&edit=1
Bug #48860 [Opn->Csd]: SplQueue objects can not be stored in session
Edit report at https://bugs.php.net/bug.php?id=48860&edit=1 ID: 48860 Updated by: le...@php.net Reported by:dave at dtracorp dot com Summary:SplQueue objects can not be stored in session -Status: Open +Status: Closed Type: Bug Package:SPL related Operating System: * PHP Version:5.3, 6 -Assigned To: +Assigned To:levim Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-07-24 23:40:57] ras...@php.net Automatic comment on behalf of colder Revision: http://git.php.net/?p=php-src.git;a=commit;h=c13f2c3e2c22829d58d6f5b9b8106ae76b580b52 Log: Fix #48860 Implement Serialization for DLL [2012-04-18 09:49:51] larue...@php.net Automatic comment on behalf of colder Revision: http://git.php.net/?p=php-src.git;a=commit;h=c13f2c3e2c22829d58d6f5b9b8106ae76b580b52 Log: Fix #48860 Implement Serialization for DLL [2011-07-12 17:45:10] col...@php.net Serialization implemented as of 5.4 [2011-07-12 17:43:14] col...@php.net Automatic comment from SVN on behalf of colder Revision: http://svn.php.net/viewvc/?view=revision&revision=313183 Log: Fix #48860 Implement Serialization for DLL [2009-08-07 10:29:31] j...@php.net This is just missing feature. Several other SPL classes also don't implement the Serializable interface. 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=48860 -- Edit this bug report at https://bugs.php.net/bug.php?id=48860&edit=1
Req #47172 [Opn->Wfx]: new interface suggest
Edit report at https://bugs.php.net/bug.php?id=47172&edit=1 ID: 47172 Updated by: le...@php.net Reported by:info at netmosfera dot it Summary:new interface suggest -Status: Open +Status: Wont fix Type: Feature/Change Request Package:SPL related Operating System: irrelevant PHP Version:5.3.0alpha3 Block user comment: N Private report: N Previous Comments: [2009-01-20 19:43:29] info at netmosfera dot it another useful interface: interface PrintReadable { public printR(); } print_r(new ArrayObject(.)); useful to improve readability on items like this: ArrayObject Object ( [storage:ArrayObject:private] => Array ( [0] => ArrayObject Object ( [storage:ArrayObject:private] => Array ( [0] => ArrayObject Object ( [storage:ArrayObject:private] => Array ( ) ) ) ) [1] => ciao ) ) [2009-01-20 18:34:50] info at netmosfera dot it Description: hello please read the code! hth Reproduce code: --- interface FirstLast //? lol! { public function (Boolean) isFirst(); public function (Boolean) isLast(); } $x= new ArrayObject(Array(1,2,3,4,5,6,7)); // implements this.. foreach($x as $item) { if($x->isFirst()) echo ""; echo "" . $item . ""; if($x->isLast()) echo ""; } -- Edit this bug report at https://bugs.php.net/bug.php?id=47172&edit=1
Bug #63508 [Opn]: LimitIterator should implement SeekableIterator
Edit report at https://bugs.php.net/bug.php?id=63508&edit=1 ID: 63508 Updated by: le...@php.net Reported by:le...@php.net Summary:LimitIterator should implement SeekableIterator Status: Open Type: Bug Package:SPL related PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I just noticed something: LimitIterator::seek returns int; SeekableIterator::seek returns void; When they were created they should have been made to match. That's probably why LimitIterator didn't implement SeekableIterator, though. Is this a problem? Previous Comments: [2012-11-13 23:08:35] le...@php.net The following patch has been added/updated: Patch Name: LimitIterator_implement_SeekableIterator Revision: 1352848115 URL: https://bugs.php.net/patch-display.php?bug=63508&patch=LimitIterator_implement_SeekableIterator&revision=1352848115 [2012-11-13 23:00:40] le...@php.net The following patch has been added/updated: Patch Name: LimitIterator_implement_SeekableIterator Revision: 1352847640 URL: https://bugs.php.net/patch-display.php?bug=63508&patch=LimitIterator_implement_SeekableIterator&revision=1352847640 [2012-11-13 23:00:18] le...@php.net Description: LimitIterator already implements SeekableIterator; it just doesn't do so formally. Test script: --- seek(2); var_dump($iterator->current()); Expected result: bool(true) bool(true) int(3) Actual result: -- bool(false) bool(true) int(3) -- Edit this bug report at https://bugs.php.net/bug.php?id=63508&edit=1
Req #49538 [Opn->Wfx]: ArrayAccess Force implement append
Edit report at https://bugs.php.net/bug.php?id=49538&edit=1 ID: 49538 Updated by: le...@php.net Reported by:kevinpeno at gmail dot com Summary:ArrayAccess Force implement append -Status: Open +Status: Wont fix Type: Feature/Change Request Package:SPL related Operating System: ALL PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Thank you for your input. However, the current API allows you to override the append behavior. It may have been nice to have split these when they were created, but it has already been finished and it's not going to change. function offsetSet($k, $v) { if ($k === NULL) { $this->append($v); } else { parent::offsetSet($k, $v); } } Previous Comments: [2009-09-12 22:18:50] kevinpeno at gmail dot com Dumbass moment on the offsetSet bug. Please ignore that part :P The rest I still would like to see though :) [2009-09-12 22:16:28] kevinpeno at gmail dot com Description: ArrayAccess should force the implementation of append to cover the case of $array[] = somevalue so that one can properly handle values appended in this manner. Additionally, most internal classes implementing ArrayAccess add their own append method anyway and this would provide some sort of naming standard. Examples of conflicts in naming include ArrayObject::append() and SplDoublyLinkedList::push() Reproduce code: --- http://bugs.php.net/bug.php?id=49537 var_dump( 'offsetSet:', $k, $value ); } } $test = new MyArrayObject(); $test[] = 'test'; ?> Expected result: MyArrayObject::append() called rather than MyArrayObject::offsetSet() Actual result: -- MyArrayObject::offsetSet() is called -- Edit this bug report at https://bugs.php.net/bug.php?id=49538&edit=1
Bug #55406 [Opn->Nab]: get_object_vars and array casting when extending ArrayObject
Edit report at https://bugs.php.net/bug.php?id=55406&edit=1 ID: 55406 Updated by: le...@php.net Reported by:chrisstocktonaz at gmail dot com Summary:get_object_vars and array casting when extending ArrayObject -Status: Open +Status: Not a bug Type: Bug Package:SPL related Operating System: Linux PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: This is the expected behavior (I think). ArrayObject is complex and doesn't work as most people would expect. It's hard for me to keep straight sometimes. You need to set the STD_PROP_LIST bit for this to behave the way you are expecting. Previous Comments: [2011-08-12 11:09:39] RQuadling at GMail dot com Adding ... public function __construct (array $input = array(), $flags = ArrayObject::STD_PROP_LIST, $iterator_class = 'ArrayIterator') { parent::__construct($input, $flags, $iterator_class); } as the constructor for TestTwo will output ... array(1) { ["TestOne_1"]=> int(1) } array(1) { ["TestOne_1"]=> int(1) } array(1) { ["TestTwo_1"]=> int(1) } array(1) { ["TestTwo_1"]=> int(1) } array(2) { ["TestThree_1"]=> int(1) ["TestTwo_1"]=> int(1) } array(2) { ["TestThree_1"]=> int(1) ["TestTwo_1"]=> int(1) } So, is this a bug? Dox says ... "ArrayObject::STD_PROP_LIST Properties of the object have their normal functionality when accessed as list (var_dump, foreach, etc.)." So, without this flag (a bitmask) being set, the "properties" aren't accessible in the way you think they should be. [2011-08-11 20:41:44] chrisstocktonaz at gmail dot com My expected result had a typo, "TestOne_1" would not exist in testtwo or testthree classes. Here is a patch for this: --- ext/spl/spl_array.c 2011-07-25 04:35:02.0 -0700 +++ ext/spl/spl_array.c 2011-08-11 13:38:52.0 -0700 @@ -746,7 +746,12 @@ { spl_array_object *intern = (spl_array_object*)zend_object_store_get_object(object TSRMLS_CC); - return spl_array_get_hash_table(intern, 1 TSRMLS_CC); +HashTable *hh = zend_std_get_properties(object TSRMLS_CC); +HashTable *ht = spl_array_get_hash_table(intern, 1 TSRMLS_CC); + +zend_hash_merge(hh, ht, NULL, NULL, sizeof(zend_class_entry *), 0); + + return hh; } /* }}} */ static HashTable* spl_array_get_debug_info(zval *obj, int *is_temp TSRMLS_DC) /* {{{ */ [2011-08-11 19:59:18] chrisstocktonaz at gmail dot com Description: As discussed on internals mailing list here [1], ArrayObject I think is overriding the get_properties handler in a bit to simple of a way. I think the ArrayObject should merge the spl hash with the default handler. [1] http://news.php.net/php.internals/54508 Test script: --- --Code class TestOne { public $TestOne_1 = 1; } class TestTwo extends ArrayObject { public $TestTwo_1 = 1; } class TestThree extends TestTwo { public $TestThree_1 = 1; } $t1 = new TestOne; var_dump((array) $t1, get_object_vars($t1)); $t2 = new TestTwo; var_dump((array) $t2, get_object_vars($t2)); $t3 = new TestThree; var_dump((array) $t3, get_object_vars($t3)); Expected result: array(1) { ["TestOne_1"]=> int(1) } array(1) { ["TestOne_1"]=> int(1) } array(0) { // TestOne_1 // TestTwo_1 } array(0) { // TestOne_1 // TestTwo_1 } array(0) { // TestOne_1 // TestTwo_1 // TestThree_1 } array(0) { // TestOne_1 // TestTwo_1 // TestThree_1 } Actual result: -- array(1) { ["TestOne_1"]=> int(1) } array(1) { ["TestOne_1"]=> int(1) } array(0) { } array(0) { } array(0) { } array(0) { } -- Edit this bug report at https://bugs.php.net/bug.php?id=55406&edit=1
Bug #45595 [Asn->Nab]: ArrayObject::STD_PROP_LIST does not behave as documented with foreach
Edit report at https://bugs.php.net/bug.php?id=45595&edit=1 ID: 45595 Updated by: le...@php.net Reported by:robin_fernandes at uk dot ibm dot com Summary:ArrayObject::STD_PROP_LIST does not behave as documented with foreach -Status: Assigned +Status: Not a bug Type: Bug Package:SPL related Operating System: * PHP Version:5.2CVS-2008-07-22 (snap) Assigned To:colder Block user comment: N Private report: N New Comment: This is not a bug, as explained by rquadling at php dot net above. Previous Comments: [2011-02-25 12:00:34] rquadl...@php.net The ArrayObject::STD_PROP_LIST doesn't seem to alter the behaviour of ArrayObject in any noticeable way. Setting properties on an instance of ArrayObject at runtime adds the properties to the instance, rather than storing them as key/value pairs in the internal array. $o->prop = val is a property with or without this flag and cannot be accessed via $o['prop'] It would seem ArrayObject::ARRAY_AS_PROPS is what turns properties into key/value pairs and allows you to access the key/value pairs as instance properties. $o->prop = val is the same as $o['prop'] = val. 'a'); // Build objects $o1 = new ArrayObject($a ); $o2 = new ArrayObject($a, ArrayObject::STD_PROP_LIST ); $o3 = new ArrayObject($a, ArrayObject::ARRAY_AS_PROPS); $o4 = new ArrayObject($a, ArrayObject::STD_PROP_LIST | ArrayObject::ARRAY_AS_PROPS); $ao = array($o1, $o2, $o3, $o4); foreach($ao as $o) { // Add a property. $o->last = 'z'; // Show flags, foreach() and properties. echo 'Flags set to ', str_pad(decbin($o->getFlags()), 2, '0', STR_PAD_LEFT), PHP_EOL, print_r($o, True), PHP_EOL, 'Foreach:', PHP_EOL; foreach($o as $k => $v) { echo " $k => $v", PHP_EOL; } echo 'Properties:', PHP_EOL, " first => {$o->first}", PHP_EOL, " last => {$o->last}", PHP_EOL, PHP_EOL; } ?> outputs (using 5.3+) ... Flags set to 00 ArrayObject Object ( [last] => z [storage:ArrayObject:private] => Array ( [first] => a ) ) Foreach: first => a Properties: Notice: Undefined property: ArrayObject::$first in Z:\ar1.php on line 29 first => last => z Flags set to 01 ArrayObject Object ( [last] => z [storage:ArrayObject:private] => Array ( [first] => a ) ) Foreach: first => a Properties: Notice: Undefined property: ArrayObject::$first in Z:\ar1.php on line 29 first => last => z Flags set to 10 ArrayObject Object ( [storage:ArrayObject:private] => Array ( [first] => a [last] => z ) ) Foreach: first => a last => z Properties: first => a last => z Flags set to 11 ArrayObject Object ( [storage:ArrayObject:private] => Array ( [first] => a [last] => z ) ) Foreach: first => a last => z Properties: first => a last => z [2008-10-24 15:56:27] j...@php.net Assigned to the SPL maintainer. [2008-07-22 17:02:41] robin_fernandes at uk dot ibm dot com Description: The SPL documentation states that if the ArrayObject::STD_PROP_LIST flag is set on an ArrayObject instance: "Properties of the object have their normal functionality when accessed as list (var_dump, foreach, etc.)" (see http://www.php.net/~helly/php/ext/spl/classArrayObject.html#daebe26f8478746da33c266a730714a9 ) This flag does affect var_dump(), but it seems to have no impact on foreach. See reproduce code. I'm not sure whether this is a functional problem or a documentation problem. Reproduce code: --- p1 = 1; $ao->p2 = 2; $ao->p3 = 3; echo "\nGet property list with var_dump:\n"; var_dump($ao); echo "\nGet property list with foreach:\n"; foreach ($ao as $key=>$value) { echo " $key=>$value\n"; } ?> Expected result: Create instance of ArrayObject and add some normal properties... Get property list with var_dump: object(ArrayObject)#1 (3) { ["p1"]=> int(1) ["p2"]=> int(2) ["p3"]=> int(3) } Get property list with foreach: p1=>1 p2=>2 p3=>3 Actual result: -- Create instance of ArrayObject and add some normal properties... Get property list with var_dump: object(ArrayObject)#1 (3) { ["p1"]=> int(1) ["p2"]=> int(2) ["p3"]=> int(3) } Get property list with foreach: 0=>x 1=>y 2=>z -- Edit this bug report at https://bugs.php.net/bug.php?id=45595&edit=1
Bug #48814 [Asn->Csd]: Subclass of RecursiveDirectoryIterator segfaults with custom constructor
Edit report at https://bugs.php.net/bug.php?id=48814&edit=1 ID: 48814 Updated by: le...@php.net Reported by:dennis at born05 dot nl Summary:Subclass of RecursiveDirectoryIterator segfaults with custom constructor -Status: Assigned +Status: Closed Type: Bug Package:SPL related Operating System: Fedora Core 6 PHP Version:5.2.10, 5.3.0 Assigned To:colder Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2009-07-20 22:01:37] fel...@php.net HEAD works fine. 5.2 and 5.3 segfaults: (gdb) bt #0 0x08412082 in _zval_ptr_dtor (zval_ptr=0xa37dc0f, __zend_filename=0x87bbafc "/home/felipe/dev/php5/Zend/zend_variables.c", __zend_lineno=175) at /home/felipe/dev/php5/Zend/zend.h:391 #1 0x08421c68 in _zval_ptr_dtor_wrapper (zval_ptr=0xa37dc10) at /home/felipe/dev/php5/Zend/zend_variables.c:175 #2 0x08434493 in zend_hash_destroy (ht=0xa37db58) at /home/felipe/dev/php5/Zend/zend_hash.c:526 #3 0x0844d749 in zend_object_std_dtor (object=0xa38460c, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/Zend/zend_objects.c:45 #4 0x0827ddff in spl_filesystem_object_free_storage (object=0xa38460c, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/ext/spl/spl_directory.c:81 #5 0x08453566 in zend_objects_store_del_ref_by_handle_ex (handle=5, handlers=0x87d0e40, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/Zend/zend_objects_API.c:220 #6 0x08453138 in zend_objects_store_del_ref (zobject=0xa37d78c, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/Zend/zend_objects_API.c:172 #7 0x0842185b in _zval_dtor_func (zvalue=0xa37d78c, __zend_filename=0x87ba958 "/home/felipe/dev/php5/Zend/zend_execute_API.c", __zend_lineno=435) at /home/felipe/dev/php5/Zend/zend_variables.c:52 ---Type to continue, or q to quit--- #8 0x08411d2c in _zval_dtor (zvalue=0xa37d78c, __zend_filename=0x87ba958 "/home/felipe/dev/php5/Zend/zend_execute_API.c", __zend_lineno=435) at /home/felipe/dev/php5/Zend/zend_variables.h:35 #9 0x08412111 in _zval_ptr_dtor (zval_ptr=0xa387cd0, __zend_filename=0x876bf7c "/home/felipe/dev/php5/ext/spl/spl_iterators.c", __zend_lineno=352) at /home/felipe/dev/php5/Zend/zend_execute_API.c:435 #10 0x0826e5d7 in spl_recursive_it_move_forward_ex (object=0xa37c814, zthis=0xa37bf40, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/ext/spl/spl_iterators.c:352 #11 0x0826e888 in spl_recursive_it_move_forward (iter=0xa37d5b4, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/ext/spl/spl_iterators.c:387 #12 0x0847bba4 in ZEND_FE_FETCH_SPEC_VAR_HANDLER (execute_data=0xa3ab6a4, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/Zend/zend_vm_execute.h:8894 #13 0x0845647b in execute (op_array=0xa37f748, tsrm_ls=0xa22d070) at /home/felipe/dev/php5/Zend/zend_vm_execute.h:104 #14 0x084252c2 in zend_execute_scripts (type=8, tsrm_ls=0xa22d070, retval=0x0, file_count=3) at /home/felipe/dev/php5/Zend/zend.c:1188 [2009-07-06 12:00:59] dennis at born05 dot nl Applies for 5.2.10 AND 5.3.0 [2009-07-06 11:59:38] dennis at born05 dot nl Description: When you subclass RecursiveDirectoryIterator and override the constructor with enhanced functionality it makes PHP segfault. I have tested this on 5.2.10 and 5.3.0, both display similar (but not equal) behaviour, the output is somewhat different, but both versions segfault. Reproduce code: --- base_path = $path; parent::__construct($path, $flags); } } $iterator = new RecursiveIteratorIterator(new MyRDI('/path/to/dir/hierarchy')); foreach($iterator as $entry) { echo $entry->getFilename()."\n"; } ?> Expected result: See a list of all the filenames Actual result: -- PHP segfaults -- Edit this bug report at https://bugs.php.net/bug.php?id=48814&edit=1
Bug #63678 [Opn->Dup]: SplObjectStorage->current() !== current(SplObjectStorage)
Edit report at https://bugs.php.net/bug.php?id=63678&edit=1 ID: 63678 Updated by: le...@php.net Reported by:Alex at phpguide dot co dot il Summary:SplObjectStorage->current() !== current(SplObjectStorage) -Status: Open +Status: Duplicate Type: Bug Package:SPL related Operating System: debian 6 PHP Version:5.4.9 Block user comment: N Private report: N New Comment: This is a duplicate of #49369 (https://bugs.php.net/bug.php?id=49369). Previous Comments: [2012-12-04 00:25:55] mail+php at requinix dot net SplObjectStorage provides ->current() as part of the implementation to Iterator/Traversable. If you want to call it directly you may need to obey the Iterator convention of calling ->rewind() first. But doing so only changes the ->current() value to be the object and not null. Even with $blat->rewind() and reset($blat) both key() and current() behave differently. In the example for SplObjectStorage::current() it includes $object = $s->current(); // similar to current($s) so I would also expect them to behave the same. tl;dr with ->rewind() and reset(): key($blat)==null, current($blat)==false $blat->key()==0, $blat->current()==a test object Without ->rewind() and reset(): key($blat)==null, current($blat)==false $blat->key()==0, $blat->current()==null [2012-12-03 21:07:18] Alex at phpguide dot co dot il Description: $SplObjectStorage->current() returns different value from current($SplObjectStorage). Test script: --- class test { public $val; public function __construct() { $this->val = rand(); } } class blat extends \SplObjectStorage { public function add() { $this->attach(new test()); } } $blat = new blat(); $blat->add(); $blat->add(); $blat->add(); $blat->add(); var_dump($blat->current() === current($blat)); // null === false Expected result: true Actual result: -- false -- Edit this bug report at https://bugs.php.net/bug.php?id=63678&edit=1
Bug #63154 [Opn->Asn]: SplDoublyLinkedList should handle list modifications from outside of the object
Edit report at https://bugs.php.net/bug.php?id=63154&edit=1 ID: 63154 Updated by: le...@php.net Reported by:maciej dot sz at gmail dot com Summary:SplDoublyLinkedList should handle list modifications from outside of the object -Status: Open +Status: Assigned Type: Bug Package:SPL related Operating System: irrelevant PHP Version:5.4.7 -Assigned To: +Assigned To:levim Block user comment: N Private report: N New Comment: This is not a bug. However, the expected work-around would be: rewind(); $list->valid(); ) { if (in_array($list->current(), array(0, 2))) { $list->offsetUnset($list->key()); } else { $list->next(); } } ?> However, this does not work. I am not entirely sure which function/functions is/are faulty here. Previous Comments: [2012-09-24 18:44:49] maciej dot sz at gmail dot com Description: When I unset more then one element while iterating through SplDoublyLinkedList object it throws an OutOfRangeException exception. Im guessing that this is because each time an the offsetUnset() method is called, the keys of the list are reset. This should not be happening until the loop is rewind()'ed. Test script: --- $List = new SplDoublyLinkedList(); $List->push('a'); $List->push('b'); $List->push('c'); $List->push('d'); foreach ( $List as $key => $value ) { echo "Current element: key = {$key}, value = '{$value}'. "; if ( in_array($value, ['b', 'd']) ) { echo "MATCH! performing unset"; unset($List[$key]); } echo "\n"; } Expected result: The elements should be removed from the list, and no exception should be thrown. At the very least it should act as the ArrayObject object: triggers a notice, but gets the job done. But the perfect solution would be the way ArrayIterator does it - clean, no errors: $Arr = new ArrayIterator(['a', 'b', 'c', 'd']); foreach ( $Arr as $key => $value ) { echo "Current element: key = {$key}, value = '{$value}'. "; if ( in_array($value, ['b', 'd']) ) { echo "MATCH! performing unset"; unset($Arr[$key]); } echo "\n"; } var_dump($Arr->getArrayCopy()); Actual result: -- OutOfRangeException -- Edit this bug report at https://bugs.php.net/bug.php?id=63154&edit=1
Bug #62107 [Opn->Csd]: SplStack serialization problem
Edit report at https://bugs.php.net/bug.php?id=62107&edit=1 ID: 62107 Updated by: le...@php.net Reported by:ozland2004 at narod dot ru Summary:SplStack serialization problem -Status: Open +Status: Closed Type: Bug Package:SPL related Operating System: CentOS 5.4 PHP Version:5.3.13 -Assigned To: +Assigned To:levim Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-05-23 05:31:46] reeze dot xia at gmail dot com SplStack makes use of SplDoubleLinkedList. It isn't serializable in PHP5.3 serialize method was introduced in PHP5.4 and 5.4 only: http://svn.php.net/viewvc?view=revision&revision=313183 http://cn2.php.net/manual/en/spldoublylinkedlist.serialize.php [2012-05-22 09:23:50] ozland2004 at narod dot ru Description: SplStack object serialization works wrong Test script: --- $t = new SplStack(); $t->push(1); var_dump(unserialize(serialize($t))); Expected result: object(SplStack)#32 (2) { ["flags":"SplDoublyLinkedList":private]=> int(6) ["dllist":"SplDoublyLinkedList":private]=> array(1) { [0]=> int(1) } } Actual result: -- object(SplStack)#31 (2) { ["flags":"SplDoublyLinkedList":private]=> int(6) ["dllist":"SplDoublyLinkedList":private]=> array(0) { } } -- Edit this bug report at https://bugs.php.net/bug.php?id=62107&edit=1
Req #55128 [Ana->Wfx]: SplFixedArray::fromArray() does not use extended class
Edit report at https://bugs.php.net/bug.php?id=55128&edit=1 ID: 55128 Updated by: le...@php.net Reported by:ar at ez dot no Summary:SplFixedArray::fromArray() does not use extended class -Status: Analyzed +Status: Wont fix Type: Feature/Change Request Package:SPL related Operating System: * PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The solution is to reimplement it in your subclass. Static functions aren't inherited in the same way. In my opinion fromArray should never have existed, but it's too late for that. Previous Comments: [2011-07-27 05:40:59] ar at ez dot no that sounds like potentially breaking code. cant see the patch from here(surfing on kindle while on vacation), but isn`t it something like "new static()" that can be used? [2011-07-26 10:10:24] larue...@php.net After much thought, I think there maybe no reason for fixedarray extended class to define it's own constructor, since we provide fixedarrary::__construct and fromArray already, and extended class should only get an instance through calling them. so I think we can make fixedarray::__construct final to make this feature works. [2011-07-26 09:57:47] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-splfixedarray-fromarray-should-return-call-scope-instance Revision: 1311674267 URL: https://bugs.php.net/patch-display.php?bug=55128&patch=php-5-3-splfixedarray-fromarray-should-return-call-scope-instance&revision=1311674267 [2011-07-26 09:49:52] larue...@php.net hmm, that's a really problem, if we want to provide this feature, we should make fixedarray::__construct final. [2011-07-26 08:36:08] cataphr...@php.net What if FixedCollection has a constructor? 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=55128 -- Edit this bug report at https://bugs.php.net/bug.php?id=55128&edit=1
Bug #63823 [Opn->Wfx]: SPL InfiniteIterator needs explicit rewind to be usable in a closure
Edit report at https://bugs.php.net/bug.php?id=63823&edit=1 ID: 63823 Updated by: le...@php.net Reported by:s...@php.net Summary:SPL InfiniteIterator needs explicit rewind to be usable in a closure -Status: Open +Status: Wont fix Type: Bug Package:SPL related Operating System: Linux PHP Version:5.4Git-2012-12-21 (Git) Block user comment: N Private report: N New Comment: By design, iterators are required to call rewind before using them. The foreach code does this for you, but since you aren't using a foreach construct and you didn't call rewind yourself it isn't happening. You are effectively using undefined behavior whenever you do this. Previous Comments: [2012-12-23 18:02:18] fel...@php.net Are you referring to bug #44063? [2012-12-21 02:35:41] larue...@php.net I saw similar report before, and remembered someone mark it as won't fix.. I just can not find the previous report now... [2012-12-21 02:20:57] s...@php.net A bigger example is: $val) { var_dump($val); } echo "\n'foreach' on InfiniteIterator\n"; $a = array('one', 'two', 'three'); $a_it = new InfiniteIterator(new ArrayIterator($a)); $i = 0; foreach ($a_it as $key => $val) { if ($i++ >= 7) break; var_dump($val); } echo "\n'for' on ArrayIterator\n"; $d = array('one', 'two', 'three'); $d_it = new ArrayIterator($d); for ($i = 0; $i < 3; $i++) { var_dump($d_it->current()); $d_it->next(); } echo "\n'for' on InfiniteIterator\n"; $b = array('one', 'two', 'three'); $b_it = new InfiniteIterator(new ArrayIterator($b)); for ($i = 0; $i < 7; $i++) { var_dump($b_it->current()); $b_it->next(); } ?> This outputs: 'foreach' on ArrayIterator string(3) "one" string(3) "two" string(5) "three" 'foreach' on InfiniteIterator string(3) "one" string(3) "two" string(5) "three" string(3) "one" string(3) "two" string(5) "three" string(3) "one" 'for' on ArrayIterator string(3) "one" string(3) "two" string(5) "three" 'for' on InfiniteIterator NULL string(3) "two" string(5) "three" string(3) "one" string(3) "two" string(5) "three" string(3) "one" So the odd behavior is with the last loop. A "real" life script (from discussion on php.internals) is: rewind(); // why is the rewind needed? $result = preg_replace_callback( '/word/', function($matches) use ($replacements_iterator) { $r = $replacements_iterator->current(); $replacements_iterator->next(); return $r; }, 'word word word word word' ); var_dump($result); // Outputs: //string(21) "one two three one two" // Without the call to $replacements_iterator->rewind(), the output is: //string(18) " two three one two" ?> [2012-12-21 02:17:17] s...@php.net Description: SPL's InfiniteIterator returns NULL for the first access, unless used in a 'foreach' loop, or a rewind is done. This means that an explicit rewind is needed before an InfiniteIterator can be safely be used in an application. Test script: --- current()); $b_it->next(); } ?> Expected result: string(3) "one" string(3) "two" string(5) "three" string(3) "one" string(3) "two" string(5) "three" string(3) "one" Actual result: -- NULL string(3) "two" string(5) "three" string(3) "one" string(3) "two" string(5) "three" string(3) "one" -- Edit this bug report at https://bugs.php.net/bug.php?id=63823&edit=1