Re: [PATCH] Loop Overflow Bug Fix

[Paige DePol <lual@...>]

KHMan <keinhong@gmail.com> wrote:

> If I thought it was an open-and-shut case I would have called it a bug and
> offered a patch. But no, perhaps my bias is that I have seen all too many
> corner cases in my time and have no desire to handle or fix each and every
> corner case. For example, for automotive firmware, one codes a only subset
> of what a language is capable of, one does not step on the slippery stuff.
> It's hardly ideal, yet this is what companies like SpaceX do successfully
> -- that is, use C++ carefully instead of Ada.

I would consider it a bug... the issue is with the implementation. If you
loop from math.maxinteger - 10 to math.maxinteger I would not expect Lua to
enter into an infinite loop. The issue is simply one of logic in the looping
code in OP_FORPREP and OP_FORLOOP. By fixing this logic it fixes the edge
case when using min/max integer values in loops... which appropriately fixes
the sample code you provided, along with all the other edge cases provided.

Look at the patch I provided... it is an open-and-shut case, the issue was
fixed by a very simple logic adjustment. The entire test suite still runs as
expected, it just removes the need for the coder to be aware of the edge
case using min/max integers as they now work as one would expect.

> I don't expect Lua to be a benign environment. Build an app with Lua
> embedded in it, and you make all sorts of function calls, some may be
> dangerous, some may have unorthodox conventions, etc. So I like myself to
> apply good coding discipline, rather than burden loops with more and more
> behaviours.

I could see your point if fixing this issue required all sorts of extra code
paths to detect and adjust for the edge cases, but that really is not the
case here. There is one extra operation per loop iteration, and a check was
added to determine if the loop should even run at all. Neither of these
additions significantly affect the performance of OP_FORPREP or OP_FORLOOP.

~Paige