php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #54931 print_r does not reset() array pointer
Submitted: 2011-05-25 23:27 UTC Modified: 2013-10-05 08:11 UTC
Votes:2
Avg. Score:2.5 ± 0.5
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: todd at magnifisites dot com Assigned: krakjoe (profile)
Status: Closed Package: Documentation problem
PHP Version: 5.3.6 OS: Any
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2011-05-25 23:27 UTC] 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-26 01:54 UTC] johannes@php.net
-Status: Open +Status: To be documented
 [2011-05-26 01:54 UTC] 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.
 [2012-04-26 20:42 UTC] 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--;
 ...
 [2012-07-03 15:48 UTC] pollita@php.net
-Package: Arrays related +Package: Documentation problem
 [2012-07-03 15:48 UTC] 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.
 [2013-10-05 08:11 UTC] krakjoe@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2013-10-05 08:11 UTC] krakjoe@php.net 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri May 17 06:01:34 2024 UTC