#5161 dict command has side effects on foreach

obsolete: 8.5.8
closed-duplicate
5
2013-01-08
2013-01-08
heinrichmartin
No

"dict keys" takes a dictionaryVALUE, but affects the variable's interpretation by foreach:

expect:/tmp$ set tcl_version
8.5
expect:/tmp$ set x {1 a 2 b 3 c 3 d 3 e} ;# store a list which also is a dictionary value
1 a 2 b 3 c 3 d 3 e
expect:/tmp$ foreach {key val} $x {puts "$key -> $val"} ;# print pairs of list elements correctly
1 -> a
2 -> b
3 -> c
3 -> d
3 -> e
expect:/tmp$ dict keys $x ;# the argument is passed by value, isn't it? (see dict or the dodekalogue)
1 2 3
expect:/tmp$ foreach {key val} $x {puts "$key -> $val"} ;# we had that very command, and x was not altered.
1 -> a
2 -> b
3 -> e
expect:/tmp$ set x ;# indeed, x was not altered
1 a 2 b 3 c 3 d 3 e

Obviously, variables are stored in best-guess-data-structures (lists, dictionaries, ...) whenever a corresponding command is used.
This performance benefit must not affect consistency.

Why does foreach treat dict-variables differently?
This should not happen, we do have "dict for"!

Discussion

  • This looks like a dupe of 3004007 and that was fixed a few years ago (in time for 8.5.9). What does [info patchlevel] report for a buggy run? I can't duplicate using your exact code with the tip of the 8.5 branch...

     
    • status: open --> pending-duplicate
     
  • heinrichmartin
    heinrichmartin
    2013-01-08

    • milestone: 3997836 --> obsolete: 8.5.8
    • status: pending-duplicate --> open-duplicate
     
  • heinrichmartin
    heinrichmartin
    2013-01-08

    My bad, I did not consider the bugfix version. We are running Debian Squeeze stable and it looks like it's finally time for backports.
    I leave it to you to close the ticket. Thanks for the help, I did not find the duplicate as it does not contain "foreach". Sorry!

     
  • This artifact has been marked as a duplicate of artifact 3004007 with reason:
    older version under test than expected

     
    • status: open-duplicate --> closed-duplicate