#2335 variable name resolution broken

obsolete: 8.5a1
closed-postponed
8
2004-05-25
2003-05-12
No

Name resolution is slightly broken in 8.4.

% set x 1
1
% unset x
% namespace eval test set x 0
0
% set x
0

Note that the temporary fix of [Bug 735335] solves this
issue - for 8.4.3 and in HEAD: the result is as it
should be:
can't read "x": no such variable

Discussion

  • miguel sofer

    miguel sofer - 2003-05-12

    Logged In: YES
    user_id=148712

    I have not managed to devise a test for this yet; the error
    seems to depend on some subtle interplay with the literal
    mechanism. It is triggered at the tclsh prompt, but
    apparently not in a sourced file (pure string evaluation)
    or a proc body (pure compilation).

     
  • Don Porter

    Don Porter - 2003-05-14
    • assigned_to: msofer --> dgp
     
  • Don Porter

    Don Porter - 2003-06-27
    • assigned_to: dgp --> msofer
     
  • miguel sofer

    miguel sofer - 2004-03-27

    Logged In: YES
    user_id=148712

    Weird stuff - something to do with literals? If we replace
    the variable name 'x' by 'y', there is no bug!!!

     
  • miguel sofer

    miguel sofer - 2004-05-22

    Logged In: YES
    user_id=148712

    Bug 735335 isnow fixed, but this one still lives ...

     
  • miguel sofer

    miguel sofer - 2004-05-22

    Logged In: YES
    user_id=148712

    Thebug is not in the obj type, but rather in the lookup
    mechanism. The bug is still present in HEAD with the
    temporary fix; a script that exposes it is
    % namespace eval a upvar x q
    % namespace eval b set x 0
    0
    % set x
    0

    What is happening in the original script is:
    - x is a shared literal (created by init.tcl)
    - 'set x 1; unset x' shimmers x to tclNsVarNameType
    - the shared literal keeps an (undefined) variable x in
    the global hashtable
    - the lookup mechanism finds the variable in the
    hashtable, and uses it
    In this new version, x is kept in the hashtable by upvar
    instead.

     
  • miguel sofer

    miguel sofer - 2004-05-22

    Logged In: YES
    user_id=148712

    The bug is present since bog knows when - at least 8.3.4
    shows the buggy behaviour in the upvar version below ...

     
  • miguel sofer

    miguel sofer - 2004-05-22
    • milestone: 283282 --> obsolete: 8.5a1
    • priority: 5 --> 8
     
  • miguel sofer

    miguel sofer - 2004-05-22

    Logged In: YES
    user_id=148712

    More fun with zombie variables - ie, those that have an
    entry in the hashtable but (flags & VAR_UNDEFINED) is true:

    % namespace eval a {}
    % upvar 0 a::q x
    % namespace eval a {set x 1; set q}
    1
    % set x
    1
    % set a::x
    can't read "a::x": no such variable

     
  • miguel sofer

    miguel sofer - 2004-05-23
    • status: open --> closed-fixed
     
  • miguel sofer

    miguel sofer - 2004-05-23

    Logged In: YES
    user_id=148712

    Closing this bug ticket - the bug introduced in tcl8.4 is
    fixed, 8.4 and 8.5 behave now the same as all previous 8.x
    (AFAICT).

    Opening [Bug 959052] for the remaining issues.

     
  • miguel sofer

    miguel sofer - 2004-05-25
    • status: closed-fixed --> closed-postponed
     
  • miguel sofer

    miguel sofer - 2004-05-25

    Logged In: YES
    user_id=148712

    Cached ns varnames still interfere with name resolution: A
    cached varName may keep a variable's name in the namespace's
    hash table, which is the resolver's criterion for existence
    (see test namespace-17.10).

    This caching now disabled, will have to wait until the
    variable name resolution is fixed.