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
