OK, but basic search on the Internet still refer to the old specification which is on the Lua.org site itself. What was unspecified is now specified since Lua 5.3 only (and I know various sites that still use Lua 5.1, and several JIT compilers that did not use these clear statements for Lua 5.3, which may now cause incompatible behavior with valid interpretations of the former less precise specification).
Yes the new spec specifies that a zero step is now a *forward* iterator only (this is an arbitrary choice of Lua 5.3, in both cases it will cause either an infinite loop or no loop executed at all, and in both cases the start value, which will be constant if loops are executed will only be compared to the limit value: if start >= limit you have an infinite loop).
What is missing (but is implied) in the 5.3 manual is the case of a missing step value; the sample code says
local ..., step = ..., tonumber(e3)
so it can return nil, then
if not (var and limit and step) then error() end
so a "nil" (unspecified) step would cause an error. The first statement of the pseudo-code should be:
local ..., step = ..., (e3 == nil and 1 or tonumber(e3))
There's still nothing that indicates clearly that the default value of the missing third _expression_ in parameter of the numeric for loop is 1 (this could still be a problem if an implementation chose to set it at -1 if start > end, but it would break lot of codes assuming that code like:
for i=1,#t do ... --[==[ operation on t[i]... ]==] ... end
where the end _expression_ "#t" could be the limit=0 (which is lower start=1) and where it is normally expected that there would be no loop performed (backward direction with an implied step=-1 should be explicitly prohibited, in the numeric for version) That same loop could be written using a generic loop (with an iterator):
for i in ipairs(t) do ... --[==[ operation on t[i]... ]==] ... end"
Such precision is present only further down in notes ("If the third _expression_ (the step) is absent, then a step of 1 is used."), but it should be integrated in the pseudo-code, unless the following Lua code:
for i in 1,10,nil do ... end
which would generate a runtime error(), but not this one: