Tcl Source Code

array set a ""
array startsearch a
s-1-a
array anymore a s-1-a
0
info exists a(dummy)
0
array anymore a s-1-a
couldn't find search "s-1-a"

The fact that actually nothing was added nor removed from
the array "a" makes me believe that we have a bug there.
If this is a regular behaviour, then docs have to be
updated
accordingly. I doubt, however, that this is the intended 
behaviour.

Logged In: YES 
user_id=148712
Originator: NO

HEAD does not seem to fail if we set createPart2 to 0! This needs a bit more study, testsuite may be incomplete. Determine if calling those read traces is still necessary (why wouldn't it?), and if so test directly. Determine if partial solution as in the patch is wanted.

Logged In: YES 
user_id=79902
Originator: NO

FWIW, I really can't care to fix this other than in the "get rid of the odd iterator" way.

Logged In: YES 
user_id=79902
Originator: NO

Perhaps the trigger of behaviour modification should be the existence of array searches?

Mind you, I'd really much rather scratch [array startsearch] and friends; adding an [array foreach] would be better. But all that's not going to happen in 8.* anyway.

File Added - 196041: trace.patch

Logged In: YES 
user_id=148712

I attach a patch against HEAD that reduces the problem,
without fixing it completely: the only case where a
non-existing element will be created is when the array has
traces. It does fix the scriptlet here, and passes the
testsuite.

This is a halfway hack; it is possible to go further (do it
only for read traces), but it gets even uglier IMO.
Reassigning for comments - let us go around once more.

Logged In: YES 
user_id=148712

From array.n: "Warning: if elements are added to or deleted
from the array, then all searches are automatically
terminated just as if array donesearch had been invoked;
this will cause array nextelement operations to fail for
those searches."

Now: the problem is that [info exists] calls
TclVarTraceExists, which sets the "create element" flag.
Thus, an element is created, and the search is terminated.
No choice about that: the hash table is changed, the cached
search data is invalid.

I tried setting that flag to 0: env-5.4 fails. The
ubiquituous env-array ...

Now, why does [info exists] call read traces? In order to
process the 'env' array properly for sure; any other reason?
In any case, changing that can break existing scripts.

Logged In: YES 
user_id=95086

Tough thing, hm? 
 
To call it a "bug" or a "consequence of complex trace mechanism" 
is quite secondary. If the issue is that complex, that we can not 
(or will not) tackle it, then it should be documented in the man page 
as "weird_won't_fix_while_too_complex" side-effect. At least this would 
save people time and money.

Logged In: YES 
user_id=80530

Replace [array set a ""]
with [array set a {b c}] and
the same "bug" is present
in Tcl 7.6.

I lack the courage to call this
a bug, rather than a consequence
of complex trace requirements
I do not fully understand.

Logged In: YES 
user_id=80530

FWIW, I tried reproducing 
this in Tcl 7.6:

% array set a ""
% array startsearch a
"a" isn't an array


!?!

Logged In: YES 
user_id=79902

Culprit is TclVarTraceExists() in tclTrace.c (or rather it's
equivalent in 8.4 which is located in tclVar.c), but I don't
know whether what it is doing is the best choice; the
comment indicates that this is a complex problem.

I really have no idea how to progress with this.

Logged In: YES 
user_id=148712

Sounds buggy to me; passing on to donal, who is (I hope)
more knowledgeable about these matters