weird behavior returning delegate

[Sean Kelly]

Carlos Santander wrote:
> Sean Kelly escribió:
>>
>> It's because you're using one function to do the asserts and another 
>> to print results, so the values returned from acc1 and acc2 may be 
>> different.  I combined the two cases by storing the result in a number 
>> then performing the assert, etc, and the errors corresponded with what 
>> was displayed.
>>
> 
> I did the same too, but that's what I don't understand: what are really 
> the correct values, the ones that are printed or the ones that pass the 
> asserts?

When you enter the realm of undefined behavior, anything goes.  In this 
case I think the residual stack data is just a bit different in foo() 
and bar(), possibly because bar() is called before foo() or simply as an 
artifact of different code generation, so the calls that break are 
different in each case.

> Also, I don't think putting them in one, two or more functions really 
> matters. I would expect the previous acc1 and acc2 to be gone when the 
> function exits.

Yes but the delegates are referencing invalid stack locations, and so 
there's no guarantee that the data will be the same even if the basic 
sequence of calls is similar for both foo() and bar().

> Anyway, bottom line is I think I'm hoping for too much. Unless something 
> like Burton's proposed "new delegate" syntax is put into the language, 
> this wouldn't really work properly.

Yeah.  I think it might work if acc() accepted 'n' as 'inout', but doing 
so still seems a bad idea as the delegate's stack context is technically 
invalid at the point where it's called by foo() and bar().


Sean