Tcl Source Code

% namespace eval one {
    namespace export foo
    proc foo {} {}
}
% namespace eval two {
    namespace export foo
    namespace import ::one::foo
}
% namespace eval three {
    namespace export foo
    namespace import ::two::foo
}
% namespace eval two namespace import -force ::three::foo
% namespace origin two::foo     

...leaves Tcl hung in an internal
infinite loop.

The import loop prevention check
inside Tcl_Import only prevents
"end-to-end" loops, not lesser
cycles of reference.

Logged In: YES 
user_id=80530

Patch committed to HEAD
and 8-4-branch.

File Added - 100907: 1017299.patch

Logged In: YES 
user_id=80530

having looked into the internals
quite a bit now, I think I had the
wrong idea about "snapshot
semantics".  Appears that phrase
is only intended to refer to 
export sets, not to the very definition
of commands.

Note another bug.  Tcl_Import
accepts as an argument the
namespace to import into, and
if that argument is NULL, uses
the current namespace of the interp.
When checking for import loops,
the current namespace of the interp
is checked, rather than the namespace
to import into.

Here's a patch for the bugs.

Logged In: YES 
user_id=80530


miguel points out that would
change the following script
behavior:

%  namespace eval a {namespace export *; proc a {} {puts hi}}
%  namespace eval b {namespace export *;namespace import ::a::a}
%  namespace eval c {namespace import ::b::a}
% c::a
hi
% namespace eval b {proc a {} {puts lo}}
% c::a
lo
% b::a
lo
% a::a
hi

From my perspective, that code just
demonstrates that we have an
"inconsistent [namespace import] model"
(See Bug 565823).  Do we implement
snapshot semantics or not?

But, it's probably unchangeable at
this point.

Logged In: YES 
user_id=80530


In the spirit of "snapshot semantics"
I think this bug can be fixed by not
using import chains internally.  Have
each import refer directly to its origin.