From: SourceForge.net <no...@so...> - 2006-10-01 00:20:51
|
Bugs item #994454, was opened at 2004-07-20 09:08 Message generated for change (Comment added) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=994454&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 45. Traces Group: obsolete: 8.4.6 Status: Open Resolution: None Priority: 5 Submitted By: Zoran Vasiljevic (vasiljevic) >Assigned to: Donal K. Fellows (dkf) Summary: False [info exists] breaks [array anymore] Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: miguel sofer (msofer) Date: 2006-09-30 21:20 Message: 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. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2006-09-30 21:10 Message: 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. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2004-08-03 12:08 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-08-03 11:33 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-08-03 11:29 Message: 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 !?! ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2004-08-03 06:32 Message: 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. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-07-20 09:21 Message: Logged In: YES user_id=148712 Sounds buggy to me; passing on to donal, who is (I hope) more knowledgeable about these matters ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=994454&group_id=10894 |