Re: pairs / ipairs protection

["Wim Couwenberg" <w.couwenberg@...>]

> There are a couple of things that it doesn't catch.
> One is the *removal* of table entries (ie. assignment of nil
> to them) while iterating.

But then again, this isn't harmfull, so it's not really necessary to catch
this situation.  (There was a longish thread --inspired by you-- on zapping
table entries a while ago.)  You could theoretically relax your block_write
function a bit by allowing an assignment to a nil-valued (but existing) key.
However, this situation can not properly be detected it seems.  I tried
something along the following lines:

local function block_write(tab, key, value)
    if pcall(next, tab, key) then
        -- OK to assign: nil-valued key
        -- (use old __newindex if it exists)
    else
        error "No you don't!"
    end
end

It turns out though that the condition is _always_ met...  Just before the
call to __newindex (i.e. block_write), an entry for the given key will
_always be created_ in the table.  This also means that it is not possible
to _ignore_ illegal assignments (emitting just a warning) because the
disaster already has happened at that point!  Hum... maybe luaV_settable in
lvm.c should be less intrusive in this case?

Bye,
Wim