php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21702 nested foreach on same array using reference fails
Submitted: 2003-01-16 20:05 UTC Modified: 2003-01-22 00:45 UTC
Votes:11
Avg. Score:3.5 ± 1.4
Reproduced:8 of 9 (88.9%)
Same Version:6 (75.0%)
Same OS:6 (75.0%)
From: vdvo at vdvo dot net Assigned:
Status: Wont fix Package: Scripting Engine problem
PHP Version: Any OS: Any
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-01-16 20:05 UTC] vdvo at vdvo dot net
Try this:
<?php
        $a = array(1, 2);
        $ref =& $a;
        foreach ($ref as $b) {
                echo "outer: $b<br>\n";
                foreach ($a as $c)
                        echo "-- inner: $c<br>\n";
        }
?>

The output is:
outer: 1
-- inner: 1
-- inner: 2
(i.e., the processing stops after the first iteration of the outer foreach). If I understand the docs well, the output should be:
outer: 1
-- inner: 1
-- inner: 2
outer: 2
-- inner: 1
-- inner: 2
When you remove the ampersand from the assignment to $ref, it works as expected.

The documentation is a bit unclear on this. It says "Also note that foreach operates on a copy of the specified array, not the array itself, therefore the array pointer is not modified as with the each() construct...", which leads me to believe that the sample code should work. But then it goes on to say: "However, the internal pointer of the original array *is* advanced with the processing of the array.", which seems to contradict the first quotation???

This is probably a dupe of bug #14607, but that one is closed as "bogus" and I can't reopen it. Also see bug #5052, which is similar but not quite, and it's closed.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-17 02:23 UTC] moriyoshi@php.net
Actually this is a dupe of bug #14607, but this PR is much more
concise than that, so I'm going to keep 14607 bogus and make this alive.

Since foreach() uses "internal array pointer" and references are designed 
to share one such pointer, the deeper loop gets confused and your script never
gives the expected result.

Virtually the script can be rewritten as...

<?php
	$a = array(1, 2);
	for ($ptr = 0; $ptr < count($a); $ptr++) {
		$b = $a[$ptr];
		echo "outer: $b <br />\n";
		for ($ptr = 0; $ptr < count($a); $ptr++) {
			$c = $a[$ptr];
			echo "inner: $c <br />\n";
		}
	}
?>

Marking this as a documentation problem.
 

 [2003-01-17 06:20 UTC] moriyoshi@php.net
Sorry, I meant the outer loop gets confused; not the deeper loop.

 [2003-01-17 06:29 UTC] vdvo at vdvo dot net
> Marking this as a documentation problem.

I was sooo very much afraid you would do exactly this! :-(

So it is really intended to work like this? You don't find there is anything wrong with the foreach construct?

Consider this: this means that you CAN'T use foreach at all in cases where you don't know for certain whether you couldn't have possibly been called from a foreach over the same array (or a reference to it, in fact).

Also, you CAN'T use foreach in a case like mine, in which I found this problem:

foreach ($obj->arr as $elem) {
    ...
    $obj->method($elem);
    ...
}

What if the method also wants to iterate over the array? You don't know, it wasn't you who wrote the class library...

Also, I find this very inconsistent. I didn't mention it in the original description, but you know what? When you nest two foreach's using the VERY SAME variable, it magically works! How is it possible that two references to the same variable are somehow more equivalent than the variable is to itself??? :-o

No, I don't agree that this is just a documentation problem. Marking as a scripting engine problem again. You may disagree, of course, but please, give it a thought. Or perhaps some discussion. Thanks.
 [2003-01-17 07:36 UTC] moriyoshi@php.net
Although I admit that the behaviour is quite inconsistent, we won't fix this anyway because the issue's all up to the language design.

> Also, I find this very inconsistent. I didn't mention it in the original
> description, but you know what? When you nest two foreach's using the
> VERY SAME variable, it magically works! How is it possible that two
> references to the same variable are somehow more equivalent than the
> variable is to itself??? :-o

Well, it looks like a magic.

To say more precisely, foreach statement always makes use of a copy of the given array instead of the original itself unless the array is a reference or has a reference.

That's the reason you could get along with nested foreach loops in general case. Thus the following while loop (A) is an equivalent to (B).

<?php /* A */
	$copy_foo = $a;
	reset($copy_foo);
	while (list(,$b) = each($copy_foo)) {
		$copy_bar = $a;
		reset($copy_bar);
		while (list(,$c) = each($copy_bar)) {
			print $c;
		}
	}
?>

<?php /* B */
	$a = array(1, 2);
	foreach ($a as $b) {
		foreach ($a as $c) {
			print $c;
		}
	}
?>

Related bugs: http://bugs.php.net/bug.php?id=8353


 [2003-01-17 08:27 UTC] vdvo at vdvo dot net
> Although I admit that the behaviour is quite inconsistent,
> we won't fix this anyway because the issue's all up to the
> language design.

Well, I dunno. In bug #8353, philip@php.net says: "...the following note exists in the foreach() entry of the manual and has for over two years:

Note:  Also note that foreach operates on a copy of the specified array, not the array itself, therefore the array pointer is not modified as with the each()  construct and changes to the array element returned are not reflected in the original array."

The documentation has been changed very recently.

To me, this seems like re-defining the language. (Or "changing the rules in the middle of the game", if you prefer.) Instead of fixing the bug, you say it's a feature and change the docs. That seems very Microsoft-ish. Plus, such a language construct is inconsistent, unintuitive and seriously limited in usability.

> foreach statement always makes use of a copy of the given
> array instead of the original itself unless the array is a
> reference or has a reference.

The "makes a copy" part is in the docs, and is what I expect. The "unless..." part is (still) not in the docs and seems non-sensical. In fact, in "What References Do", the manual says about what happens after "$a =& $b" the following: "Note:  $a and $b are completely equal here, that's not $a is pointing to $b or vice versa, that's $a and $b pointing to the same place." Nowhere in the manual it says that references are special. It just says that a reference is another name for the same variable. I don't see why foreach treats them specially.

Note that I'm not advocating for changing the documentation; I'm actually strongly supporting what the documentation says and has said for a long time, and that means foreach is what needs to be changed.

BTW, does the "unless..." part of the above quotation mean that when I do
$a =& $b;
foreach ($a as $elem)
    $elem->change_self();
it will work - because foreach is not working with a copy of the array? I suppose not, because it will surely make a copy of each element, right? Can I then coerce it by first making an array of references to every element, so that foreach will treat the elements specially?

Wow, this is even nastier than I thought! ;-)

Let's make a vote on the front page of php.net:
- Foreach Pro-consistency Front
program: repair foreach, return docs to previous state
- Conservative Foreach Party
program: keep foreach as is, make docs even more clear
 [2003-01-17 10:22 UTC] moriyoshi@php.net
No matter what you call this, as a convention of open-source projects, documentation is generally supposed to come up after coding stuff. In other words, the codes determine the design, and the documents are often elusive as there are some cases where they don't reflect the actual behaviour.

Regarding the nastiness of references, it's special not only for foreach, but also for the following case.

<pre><?php
	$foo = array('test');
	$bar = &$foo[0];

	print "{$foo[0]}\n";

	function test($foo) {
		$foo[0] = '???';
	}

	test($foo);

	print "{$foo[0]}\n";
?></pre>

Surprisingly, this script results in
------
test
???
------
For more about this, see bug #20993 (this is also marked as a doc-problem).

 [2003-01-17 11:55 UTC] vdvo at vdvo dot net
> No matter what you call this, as a convention of open-source
> projects, documentation is generally supposed to come up
> after coding stuff.

"Supposed to"? I hope not. It does, usually, that's true. But in this case, there _was_ documentation, and the program doesn't conform to it. And we're talking about language semantics, not something insignificant like configuration options.

> the codes determine the design

Tell me which programming language interpreter or compiler was created this way?

As for the other nastiness example that you provided, it certainly does seem nasty. Should that mean "there is at least another one nastiness, so that is a good enough excuse to make ad-hoc language design decisions"? I don't get it.

And yes, a language design decision it is, and it must be made. Either we correct the documentation (it's still not completely clear, though at least it's not so undoubtedly incorrect as two months ago), or we correct the implementation. Judging by the lack of interest so far (this is only the second bug report that I know of, and the docs have been incorrect for more than two years), not many people are relying on the current (broken) behaviour. (Anyway, why would anyone rely on such a thing?) Thus, we have a great opportunity to do the Right Thing!

Anyway, I'm leaving for the weekend right now, so don't close this bug before I can have another round at it on Monday, ok? ;-)
 [2003-01-17 12:12 UTC] derick@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

not a bug
 [2003-01-21 23:01 UTC] vdvo at vdvo dot net
Reopening due to lack of evidence that this is not a bug. Derick has not answered my email, he has not provided an explanation in his bug-closing comment, I have not found any discussion about this in the php-dev mailing list archive, and until recently, the behaviour has been in direct contradiction with the manual (while now the manual is unclear). Therefore, I have to assume that the statement "this is not a bug" is unfounded. I thought that this was an open source project?

And even if the current behaviour was really intended, the documentation needs to be clarified.

Let me ask three questions:
1) Is the current behaviour optimal?
2) If not, is it too late to correct it (because of backward compatibility)?
3) If not, is it important enough to invest time in it?

My opinion: no, no, depends on who's time is in question. ;-)
 [2003-01-21 23:11 UTC] sniper@php.net
1. No
2. Yes
3. No

 [2003-01-22 00:21 UTC] john@php.net
I don't want to cause too much of a fuss about this -- but after looking at it myself I do think it has some merit... There is no reason why by simply adding a reference to the array in question the foreach() statement should suddenly change it's behavior. I've seen "incorrect" behaviors in ZE not be treated as bogus before (such as when working with bit operations) -- this seems to fall under a simliar category. 

At the very least, it's a feature/change request. 


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 09:01:27 2024 UTC