Req #60577 [Opn->Ver]: count(new EmptyIterator) returns 1

2013-09-12 Thread levim
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

2013-09-12 Thread levim
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

2013-09-12 Thread levim
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()

2013-09-21 Thread levim
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

2013-09-21 Thread levim
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

2012-11-13 Thread levim
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

2012-11-13 Thread levim
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

2012-11-13 Thread levim
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

2012-11-13 Thread levim
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

2012-11-14 Thread levim
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

2012-11-16 Thread levim
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

2012-11-16 Thread levim
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

2012-11-16 Thread levim
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)

2012-12-08 Thread levim
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

2012-12-08 Thread levim
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

2012-12-08 Thread levim
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

2013-02-05 Thread levim
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

2013-02-05 Thread levim
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