Tcl Source Code

View Ticket
Login
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: