Bug #54931 [Opn->Csd]: print_r does not reset() array pointer

Edit report at https://bugs.php.net/bug.php?id=54931&edit=1 ID: 54931 Updated by: krakjoe@php.net Reported by: todd at magnifisites dot com Summary: print_r does not reset() array pointer -Status: Open +Status: Closed Type: Bug Package: Documentation problem Operating System: Any PHP Version: 5.3.6 -Assigned To: +Assigned To: krakjoe Block user comment: N Private report: N New Comment: print_r does not, and did not, accept by reference; I would not expect any internal pointer to be affected. each does accept by reference ... reset is no longer mentioned on the print_r documentation. There is no need for this bug to remain open. Previous Comments: ------------------------------------------------------------------------ [2012-07-03 15:48:39] pollita@php.net I disagree, but differently. Behavior should be defined, and it should be defined as what it is now. print_r() does not modify the internal pointer (nor should any internal iterative function unless it has a very good reason to). Changing this to a documentation problem. ------------------------------------------------------------------------ [2012-04-26 20:42:44] roeitell at gmail dot com IMO no harm in adding a defined state - on the contrary - and easily doable and maintainable. We can commit to a stable defined state in the future, even for users using the func for debugging. (debugging scripts, internal outputs / reporting such as "nightly mail reports" etc.) On zend.c#415, we can simply add -- ... print_hash(write_func, Z_ARRVAL_P(expr), indent, 0 TSRMLS_CC); zend_hash_internal_pointer_reset(Z_ARRVAL_P(expr)); /* new line */ Z_ARRVAL_P(expr)->nApplyCount--; ... ------------------------------------------------------------------------ [2011-05-26 01:54:24] johannes@php.net As print_r is aimed as a debugging help we should document this as "undefined" behavior so we can change it any time. Users should still be advised to use reset() if they want a defined state. ------------------------------------------------------------------------ [2011-05-25 23:27:57] todd at magnifisites dot com Description: ------------ The PHP documentation states: Remember that print_r() will move the array pointer to the end. Use reset() to bring it back to beginning. But after using print_r() on an array, the array pointer is not reset. This is the same as Bug #8289 from PHP 4 in the year 2000: http://bugs.php.net/bug.php?id=8289 Test script: --------------- $arr['a'] = 'Apple'; $arr['b'] = 'Banana'; $arr['c'] = 'Corn'; print_r($arr); //reset($arr); while(list($k,$v) = each($arr)) echo "$k => $v\n"; Expected result: ---------------- Since print_r moves the array pointer to the end I would expect FALSE to be returned by each() and nothing to be printed. However, I also note that foreach() has some side effects so perhaps this is not necessarily a bug but a documentation issue? foreach() notes: http://www.php.net/manual/en/control-structures.foreach.php Note: Unless the array is referenced, foreach operates on a copy of the specified array and not the array itself. foreach has some side effects on the array pointer. Don't rely on the array pointer during or after the foreach without resetting it. Actual result: -------------- Array ( [a] => Apple [b] => Banana [c] => Corn ) a => Apple b => Banana c => Corn ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=54931&edit=1