Re: Major Bug in Interpreter [Attn: Robert Craig]
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 13, 2005
- 471 views
Mario Steele wrote: > I just wanted report this bug before 2.5 went Final, cause this is indeed > a major bug. I've tested this under 2.5 and 2.4, and 2.4 works correctly, > but 2.5 does not. You can see it happening when you invoke the trace > like I have it written. > > }}} <eucode> > with trace > sequence stack > > constant NewValue = {0,0,1,0} > stack = {} > > trace(1) > function recursive_call(integer i) > integer ib > stack &= 0 > ib = length(stack) > stack[ib] = NewValue > for x = 1 to 4 do > if stack[ib][i] = 0 then > stack[ib][i] = recursive_call(i+1) > end if > end for > return ib > end function > > integer i > i = recursive_call(1) > ? stack > machine_proc(26,0) > </eucode> {{{ It's not a bug. It's a change in the way things work in a rare, ambiguous, and undocumented area. I should mention this in the 2.5 alpha release notes or somewhere. In order to efficiently support the new $ feature, I had to change the order of operations when subscripts are performed on the left-hand-side of an assignment. e.g. stack[ib][i] = recursive_call(i+1) In 2.4, all expressions are evaluated first, then the lhs subscripting is performed and the rhs value is assigned. In 2.5, I (generally) need to perform each lhs subscript as I go along, from left to right, before evaluating the subscript expression that comes after it, since I may need to know the proper value of $ in the subsequent subscript expression. In 2.4, you obviously counted on recursive_call() being completed before the subscripted assignment was done, and you counted on stack being changed by the side-effects of that call, before the assignment to stack was done. None of this was documented in the Reference Manual. You just tried it, and it worked. In 2.5, the lhs var being subscripted will keep its original value (I just increment its ref count), and will then be modified by the assignment. The effect of any side-effects on that var (i.e. stack) will be lost as the assignment is completed. If I don't preserve the original value, I can easily have crashes due to your having "pulled the rug out from under me" while I'm in the middle of trying to subscript a now non-existent value. And, no, I don't want to insert checks all over the place for this bizarre situation. You only have to worry about this change if you are doing a subscripted assignment with multiple subscripts on the lhs, and in the same statement you are calling a function that has the side-effect of modifying the lhs var (even as it is being assigned-to). You can make things work the way you want, and also make your code more readable, by performing the function call in a separate statement before trying to modify the lhs variable. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com