Ticket UUID: | 577033 | |||
Title: | tcl_findLibrary sets 'varName' on fail | |||
Type: | Bug | Version: | obsolete: 8.4a5 | |
Submitter: | vincentdarley | Created on: | 2002-07-03 16:07:02 | |
Subsystem: | 38. Init - Library - Autoload | Assigned To: | dgp | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2002-07-04 03:14:32 | |
Resolution: | Fixed | Closed By: | dgp | |
Closed on: | 2002-07-03 20:14:32 | |||
Description: |
Basic problem: tcl_findLibrary is supposed to set the variable $varName to the directory containing a specific file, if that file is successfully found and sourced. However, if the procedure is unable to find the file, it still sets $varName to the last location that was looked at. This can have unfortunate side effects... Example of the problem: If any extension wants to call tcl_findLibrary twice (because, perhaps for legacy reasons, the pkg.tcl file it is looking for could be in two different places), then between the two calls, a 'Tcl_UnsetVar (..., "myPkgVar", TCL_GLOBAL_ONLY) is required. Otherwise the first call to tcl_findLibrary (which we will assume fails) leaves myPkgVar set to the last directory that was looked at, and then the second call to tcl_findLibrary will only examine that location. Suggested solution: Either this constraint should be documented or tcl_findLibrary should be fixed so that if '$varName' doesn't exist when it is called, then if the procedure fails, '$varName' should also not exist when the procedure returns. | |||
User Comments: |
dgp added on 2002-07-04 03:14:32:
Logged In: YES user_id=80530 fix committed to HEAD and 8.3 branch vincentdarley added on 2002-07-04 00:00:54: Logged In: YES user_id=32170 That definitely looks like the right solution. A direct test seems to show it works -- Thanks! dgp added on 2002-07-03 23:52:39: File Added - 26336: 577033.patch Logged In: YES user_id=80530 Does this patch solve the problem? dgp added on 2002-07-03 23:34:45: Logged In: YES user_id=80530 I agree this is a bug. There's some trickiness involved in fixing it. If $varName originally exists, we do not want to unset it, even if initialization fails. Also $varName must be set during the [source] of $initScript. |
Attachments:
- 577033.patch [download] added by dgp on 2002-07-03 23:52:39. [details]