I haven't seen the following bugs reported in the wild, but I came across them in the course of my own scripting efforts lately. They are fixed in git and snapshots. 1) Under certain conditions the loop counter variable in a function could become confused with a loop counter variable of the same name in the caller. Trivial example: <hansl> function series foo (scalar x) series s loop i=1..$nobs -q s[i] = x + i endloop return s end function nulldata 10 loop i=1..3 -q series s1 = foo(1) series s2 = foo(2) printf "i=%d\n", i endloop </hansl> If the bug is triggered, then on the second and subsequent iterations of the loop in the caller one sees "i=10" instead of the expected "i=2". It is triggered only if (a) the loop counter has the same name in caller and function, (b) the function is called more than once per iteration of the loop in the caller, and (c) there is no look-up of variable names (other than series) in the caller between the calls to the function. (For example, inserting another instance of 'printf "i=%d\n", i' between the calls to foo() would prevent the bug from triggering.) 2) Putting a "return" statement inside a loop in a function would cause a curious failure: the return would be executed prematurely, at the point when gretl was supposed to be just "compiling" the loop, not actually executing the code. Trivial example: <hansl> function scalar foo (scalar x) loop i=1..2 -q if 0 return 1 endif endloop return 0 end function eval foo(1) </hansl> Before the fix, "eval foo(1)" would give 1, unconditionally. I might add that both fixes were basically one-liners -- representing points that had been overlooked rather than major structural flaws. Allin