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

[Rolf Kalbermatter <rolf.kalbermatter@...>]

It’s not bizarre at all. Lua may be not a compiler in itself (although there exist JIT versions and similar of it) but it’s written in C. And C has the notorious feature of stating many things as not being defined for the sake of efficient implementations on all kind of hardware, including very esoteric ones. 
The Lua manuals are the canonical reference to the language and if someone went to the lengths of explicitedly stating that this is unsafe, then I’m fairly sure that it can (or at least could at some point in the past) be really unsafe. It may not be on any current version and platform but I wouldn’t count on that. Especially if you compile it on some restricted embedded hardware with an older compiler. Somehow the generated byte code may be assuming things from the compiled functions it executes that make this unsafe. 

How much you want to care is up to you but if the manual states this warning, I’m pretty sure someone likely more knowledgeable about this than most of us has spent some real time on thinking about this topic. Of course it could be just a copy paste statement, Lua isn’t the only language that says that modifying a for loop count variable inside the loop is unsafe. Some even make it simply impossible by giving the programmer only read access to it.

Rolf Kalbermatter

> On 11 Dec 2022, at 07:50, bil til <biltil52@gmail.com> wrote:
> 
> Am Sa., 10. Dez. 2022 um 20:01 Uhr schrieb Paul Ducklin <pducklin@outlook.com>:>
>> Because the manual explicitly says, “Don’t do it,”
> 
> ... of course you are somehow right, I am really obsessive here, sorry...... .
> 
>> 
>> For example, the compiler could decide to keep two copies of the variable
>> ,,, the loop counter might be a CPU register that isn’t used for anything else...
> 
> 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... . 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 :) ).