Re: How undefined is undefined behaviour?

[Robert Burke <sharpobject@...>]

On Sat, Jun 5, 2021 at 5:20 AM tehtmi <tehtmi@gmail.com> wrote:
>
> This point can surely be opposed, but I take the following perspective.
> Suppose we call "next" a few times, then add a new index, then call
> "next" again. Nothing formally connects the latter "next" call to the
> former. It is not an error to call "next" with whatever index (we do not
> need to start a "traversal" at the beginning nor proceed in any
> particular order); it just returns the next index like the manual says.
> The undefined behavior is only undefined based on an abstracted
> perspective ("traversal") which cannot be known by the language
> implementation, so the language implementation must not behave badly
> (nor even throw an error).
>
> The statement in the manual is just a friendly reminder that the order
> of indices might change.

I hope this is all correct. My impression is that this paragraph does
not place any restrictions on the use of next with keys that are known
to be in the table for some reason other than that they were
previously returned by next:

"Allows a program to traverse all fields of a table. Its first
argument is a table and its second argument is an index in this table.
A call to next returns the next index of the table and its associated
value. When called with nil as its second argument, next returns an
initial index and its associated value. When called with the last
index, or with nil in an empty table, next returns nil. If the second
argument is absent, then it is interpreted as nil. In particular, you
can use next(t) to check whether a table is empty."

It seems difficult to say "If you know that a key k is in a table t
because you got it from next(t,x), and you have added a new key to t
since then, then calling next(t,k) may format your hard drive, but if
you know that the key is in the table for any other reason and you
call next(t,k) then it is not permitted to format your hard drive."