| Ticket UUID: | 600812 | |||
| Title: | upvar can create unusable variable | |||
| Type: | Support | Version: | None | |
| Submitter: | dgp | Created on: | 2002-08-27 14:26:39 | |
| Subsystem: | None | Assigned To: | msofer | |
| Priority: | 7 High | Severity: | ||
| Status: | Closed | Last Modified: | 2009-07-29 19:41:45 | |
| Resolution: | Closed By: | msofer | ||
| Closed on: | 2004-04-28 13:13:17 | |||
| Description: |
set scalar test
array set array {foo bar}
upvar 0 scalar array(grok)
set array(grok)
=> can't read "array(grok)": no such element in array
A scalar (link) variable named "array(grok)" has been
created, but there is no mechanism at the script
level for doing anything with it.
Seems [upvar] should fail rather than give something
that can't be used.
| |||
| User Comments: |
dkf added on 2009-07-29 19:41:45:
IP - Comment Removed: 130.88.1.31 dkf added on 2008-11-02 18:27:22: data_type - 210894 msofer added on 2004-04-28 20:13:17: Logged In: YES user_id=148712 Tip 184 accepted, patch committed. hobbs added on 2003-11-11 04:11:17: Logged In: YES user_id=72656 There used to be slightly different behavior in nested array in Tcl 7.x. When the requests for proper first-class array support came in, noting the then existent behavior, that was actually removed by JO. You can't do nested arrays now. This should be considered for 8.5, but really may be a 9.0 behavior for the change in error status. msofer added on 2003-11-10 23:48:28: File Deleted - 66969: File Added - 67035: 600812.patch msofer added on 2003-11-10 23:48:27: Logged In: YES user_id=148712 Patch updated; mini TIP in prep dgp added on 2003-11-10 22:33:38: Logged In: YES user_id=80530 It seems this misfeature is documented in upvar.n, and has been documented this way "forever" (since at least Tcl 7.4). Makes me wonder whether this made sense at one pont, and variable parsing rules have changed over the years to more aggressively recognize arrays? Seems we ought to have a brief TIP, if only to let the wise old men have a look and confirm we're not overlooking something. Otherwise, the patch looks fine. If it's not too much trouble, I'd update your new tests to use the -returnCodes option. You might also want to note in your new code in ObjMakeUpvar that your detection of a bad name for a scalar is consistent (and must remain consistent) with the code in TclObjLookupVar (currently line 447). msofer added on 2003-11-10 08:52:21: File Added - 66969: 600812.patch Logged In: YES user_id=148712 Attaching a patch for review - in particular, the doc changes. This does not require a TIP, does it? msofer added on 2003-10-21 05:12:39: Logged In: YES user_id=148712 Failure it will be; creating the array is quite a modification ... msofer added on 2003-10-21 05:09:18: Logged In: YES user_id=148712 Duplicated as 826708 by rmax; initial comment there: " As discussed with dkf on the Tcl'ers chat... It works as documented, and treats b(c) as a literal variable name (not as an array). But because this variable can never be accessed with [set] or $-substitution, [upvar] should rather fail on such variable names, or (IMHO better) it should create an array element, if that's possible at all." | |||
Attachments:
- 600812.patch [download] added by msofer on 2003-11-10 23:48:27. [details]