[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: pairs / ipairs protection
- From: "Wim Couwenberg" <w.couwenberg@...>
- Date: Tue, 24 Jun 2003 00:12:14 +0200
> 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)
error "No you don't!"
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?