Recursion issue with maps

[szepherd]

There was a forum topic here a while back regarding frame issues when doing recursion. I appear to be having the same problem, but with maps rather than variables.

The following code:

void recur(int[int] passed_map, int iteration);

void main(){
	int[int] map;
	map[1] = 1;
	recur(map, 0);
}

void recur(int[int] passed_map, int iteration){
	int[int] local_map;
	int intermediate;
	
	intermediate = passed_map[1];
	local_map[1] = intermediate;
	
	if(local_map[1] > 2){
		print(" Last recursion, iteration " + iteration + ":");
		print("...passed: " + passed_map[1]);	
		print("...local: " + local_map[1]);
		return;
	}
	
	local_map[1] = local_map[1] + 1;
	
	print("Pre-recursion, iteration " + iteration + ":");
	print("...passed: " + passed_map[1]);	
	print("...local: " + local_map[1]);
	
	recur(local_map, iteration +1);
	
	print("Post-recursion, iteration " + iteration + ":");
	print("...passed: " + passed_map[1]);	
	print("...local: " + local_map[1]);
}

gives these results:

Pre-recursion, iteration 0:
...passed: 1
...local: 2
Pre-recursion, iteration 1:
...passed: 2
...local: 3
Last recursion, iteration 2:
...passed: 3
...local: 3
Post-recursion,, iteration 1:
...passed: 3
...local: 3
Post-recursion,, iteration 0:
...passed: 3
...local: 3

I believe it should give this:

Pre-recursion, iteration 0:
...passed: 1
...local: 2
Pre-recursion, iteration 1:
...passed: 2
...local: 3
Last recursion, iteration 2:
...passed: 3
...local: 3
Post-recursion,, iteration 1:
...passed: 2
...local: 3
Post-recursion,, iteration 0:
...passed: 1
...local: 2

If the value being passed to the recur() function is a simple <int> instead of a map, it works fine. The problem seems to come up only when maps are being passed around. Looks like after returning from the recursive call, the contents of the local map remain that of the innermost function frame.

I've tried a number of other operations on maps in recursive functions and get the same type of results every time: the local map of the outermost (first to be called) function will always take on the values of the innermost (last to be called) iteration of the function.

Is this a bug or am I misunderstanding something?

 

[Veracity]

It's a bug. I was looking at the function call sequence for user-defined functions recently. I noticed that we save and restore parameter bindings around around the function call, specifically so that recursion would work, but we explicitly did NOT restore aggregate bindings. I frowned in puzzlement, but left it alone.

That, however, was the cause of this report, and I have now fixed it in revision 7603.

 

[szepherd]

Awesome! That's much easier than working around it. Thanks!