Re: Numeric for loop: Changing control variable REALLY dangerous?

[Viacheslav Usov <via.usov@...>]

On Sun, Dec 11, 2022 at 7:50 AM bil til <biltil52@gmail.com> wrote:

> This would be somehow bizarre concerning my understanding how Lua
> works. Please keep in mind that Lua is not a compiler-based language
> but an interpreter language - it should clearly work on any CPU, so
> Lua in no way would produce CPU-specific code...

I also find the comments about the "specification" (or "standard") vs
"implementation details" unsatisfactory, but for a different reason.

They implicitly posit that Lua is similar to a language like C, which
is formally defined by a human-readable text, which is supported (in
principle; in practice, to varying degrees) by implementations. But
that is simply not true. The Lua manual (of a recent version at least)
states plainly: "The implementation described in this manual is
available at Lua's official web site, www.lua.org." It does not try to
apply itself to other implementations. Lua is essentially what is
published at lua.org, anything else, even if it calls itself
"something Lua something" is not Lua. Moreover, each version of Lua
comes with its own manual, which applies only to that particular
version of Lua, so talking about an "arbitrary implementation" is
very, very far-fetched. Whatever the Lua "standard" says for version X
is valid only for that version of Lua, another implementation may work
in a way that is not only de facto, but also de jure different from
version X.

Ironically, an example of that is given just in the area of the
original question. One just has to compare the manuals for 5.3 and 5.4
in the part describing the numerical for statement.

Cheers,
V.
 . As far as it knows
> Lua machine has NO "hidden variables" which "live longer" than one Lua
> command. Instead all variables are present in the Lua stack. Anything
> else would also easily japordize e. g. every coroutine handling... .
>
> > Or the compiler ...in the loop “for n = 1,5” the value of n *will be exactly 5
> >at the end of the last iteration*. So if you ever set n to 6 then the loop will
> >run forever, or at least until n wraps round past 2^63...
>
> ... yes of course ... this would be bad... but this was not my
> question. (it is clear to me that you have to do such counter variable
> changes with some care... (I am an experienced C programmer - no only
> in "full stuffed Visual Studio C", but also in "less fool-proof"
> microcontroller C variants... :) ).
>
> > The fact that “it works” is not a good reason to do it… like smoking
> > a cigarette while filling up your car with petrol (gasoline). Most of the
> > time, you will be fine. But once (and never more than once) you
> >and everyone near you will not be fine at all.
>
> Nice comparison, thank you :). I just would be curious what "could
> happen"... please excuse my obsessive questioning in this case... .
>
> (maybe some "explosion experts" around here in the forum who survived
> such an "explosion" and can give a stunning report :) ).