Tcl Source Code

% namespace export after
% namespace eval foo namespace import ::after
% namespace origin foo::after
::after
% foo::after 1
% namespace origin foo::after
::foo::after

Tcl_AfterObjCmd incorrectly assumes
that objv[0] holds the name of the
built-in after command itself, and uses
Tcl_SetCommandInfo to overwrite "itself"

With [namespace import]ed commands,
though, objv[0] is the [namespace import]-created
command, not the original.  The overwrite
causes it to become an alternative
implementation of [after], rather than an
imported link to [after], as the different
[namespace origin] results demonstrate.

Logged In: YES 
user_id=99768

Changes backported, closing bug.

Logged In: YES 
user_id=99768

Changes committed to HEAD - still need to backport to 8.4

Logged In: YES 
user_id=80530

committed patch to HEAD as
a workaround of the problem.

Leaving open for the maintainer
to provide a better fix.

Logged In: YES 
user_id=79902

Ensemble -unknown callback handling was vulnerable to this
sort of nonsense.  That aspect is now Fixed (I had the
command token handy anyway for cleanup.)

Logged In: YES 
user_id=80530

BTW, it appears that the "tclAfter"
entry of interp assoc data is
nowhere used.  If that's confirmed,
you might consider abolishing it.

Hmmm.... I think I see.  Since
there's no Tcl_CmdDeleteProc
registered for [after], the database
of timer events isn't cleaned up
if/when [after] is deleted.  Storing
it as assoc data at least sees that
they are cleaned up on interp
deletion.

All this seems to suggest that
[after] really wants a real
Tcl_CreateObjCommand call
so that it can customize the
ClientData and Tcl_CmdDeleteProc
to its needs.

File Added - 99158: 1016167.patch

Logged In: YES 
user_id=80530


Attached patch corrects this specific
instance of the bug.

Note that it makes use of the
internal routine TclGetOriginalCommand
to do so.

Another fix would be to store [after]'s
data directy in an Interp field, rather than
in assocData and clientData (would also
require internals privilege).

Only fix that would be available to 
extensions would be to arrange for
the Tcl_CreateObjCommand call
that creates [after] to pass in a real
ClientData value that allows space
for mods on the fly.  That fix would
also take care of any other 
C-based wrappers, that, like [namespace
import], lead to the result of
Tcl_GetCommandFromObj(objv[0]) not
being the struct that holds the current
clientData.  There appears to be no
generally reliable way for a Tcl_ObjCmdProc
to get at the Tcl_CmdInfo of the command
currently being dispatched.  In order to
write to the ClientData, it needs to be
originally set up with space to write on.