Re: Changing tables during traversal: clearing and re-adding a field

[Dirk Feytons <dirk.feytons@...>]

On Wed, Jun 29, 2011 at 18:43, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> >But what happens if I clear an existing field and then assign to it
>> >again during one iteration? In pseudocode:
>> >
>> >for k,v in pairs(t) do
>> >   t[k] = nil
>> >   if (<some condition>) then
>> >     t[k] =<some other value>
>> >   end
>> >end
>> >
>> >Is this allowed? We've seen some intermittent errors in our code that
>> >I suspect are coming from a pattern like described above.
>> >
>> >
>> According to the letter of the manual, it is not allowed.
>> When you clear a field that field becomes non-existent. So if you
>> assign to it afterward, you violate the rule.
>>
>> I cannot say, though, if the current implementation is tolerant
>> about that and if the failures you describe actually depends on
>> that.
>
> This should not be a problem with the current implementation. When you
> create a new key, the table may rehash, and then all keys may change
> positions and the traversal goes weird. (This is the time where nil
> fields are really removed from the table, too.)  As long as you do
> not create a new key, the "erased" field is still there, and so the
> assignment does not create a new key.
>
> But Lorenzo is right that it is not "formally" allowed. You should
> try to rewrite it.

Yeah, from past messages about table rehashing I guessed it wouldn't
cause badness but since you now confirmed it's an implementation
detail I'll surely rewrite the code.
Which also means our investigation continues...


-- 
Dirk