Re: [PATCH] Loop Overflow Bug Fix

[KHMan <keinhong@...>]

On 11/19/2017 3:31 AM, Paige DePol wrote:
> KHMan <keinhong@gmail.com> wrote:
>
> > Let me just state for the record that I have no objection to the current Lua 5.3.x behaviour. Corner cases have to be handled; there are no beautiful solutions. So they are handled, but is it a good idea to start habitually relying on corner cases?
> >
> > I would just steer well and truly clear of all things slippery. No fractions in loops. No mixed numbers. No out of range numbers. No numbers close to data type limits. Just loops with zero surprises.
>
> Considering it was your example code that kicked off this entire discussion
> about the problems with loops I would have thought you would appreciate the
> patch I crated and would want to see it applied to the codebase.

IMHO it is not wrong for Lua to keep current behaviour. It's 2s 
complement arithmetic just like such a loop in C. But it would be 
nice for the ref manual to talk more about what it does with 
numeric loops. That section is maybe too brief.

Why was I initially surprised by the math.maxinteger limit not 
working? Because I don't write loops like that in normal code. Why 
then was I using math.maxinteger? Because PiL4 had this loop idiom 
using math.huge as the limit, for which the Lua VM substituted 
math.maxinteger for integer loops. Like this:

for i = 0x7FFFFFFFFFFFFFF8,math.huge do
  print(i)
  if i == -0x7FFFFFFFFFFFFFF0 then return end
end

But if we don't substitute math.huge with math.maxinteger, then 
substitute what? There are no perfect answers to that. It will 
always be some kind of special behaviour. My take is, don't touch 
that in the first place.

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.

> At least with my patch one surprise is removed when using min/max integers,
> and another when using floating loops and a step size magnitude that is
> too small to properly affect the loop variables. Thinking about what Dirk
> said as well, one final tweak could be done with floating loops by adding
> half the step size to the loop limit variable to ensure the final iteration
> is executed in the case where the floating precision drifts.

I don't have such confidence in float loops. Unless this is in 
some sort of math algorithm, I would never allow things to go 
drifting when there is another way of coding things. Therefore I 
do not see anything that needs to be fixed here.

They say C is a dangerous language, but I guess all languages have 
corner cases if one goes looking for dangerous things to do. It's 
the coder's responsibility to write robust code and algorithms.

> Granted, these are issues that probably don't come up all that often, but
> since the patch is really just a small logic shift it would seem better
> to apply it than not. Loops with zero surprises are very nice, especially
> if the language helps take care of that and not the developer! ;)

I would leave this to Roberto & co. But I would love to see a bit 
more detail in the ref manual.

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.

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia