Tcl Source Code

View Ticket
Login
Ticket UUID: 2039178
Title: Tcl_CreateTrace traces don't set TCL_INTERP_DESTROYED
Type: Bug Version: obsolete: 8.6a1
Submitter: dgp Created on: 2008-08-05 18:40:31
Subsystem: 46. Traces Assigned To: dgp
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2014-10-09 14:53:10
Resolution: Fixed Closed By: dgp
    Closed on: 2014-10-09 14:53:10
Description:
Command delete and rename traces created
by Tcl_CreateTrace (or the script interface
[trace add command]) do not set the
flag bit TCL_INTERP_DESTROYED when 
calling Tcl_CommandTraceProc callbacks.
Near as I can tell browsing the cvs logs,
they never have.

This is contrary to the documentation
for Tcl_CreateTrace.  The docs have always
claimed this flag would be set.

It appears this problem arises mostly
because the docs for Tcl_CreateTrace
were not written from the ground up, but
were written via copy/paste/fail-to-modify
applied to TraceVar.3.

The TCL_INTERP_DESTROYED flag has always
been a boneheaded interface, even in
variable traces.  There's no sensible
reason a trace callback routine needs
special notification about the interpreter
being in a state of getting deleted, when
the Tcl_InterpDeleted() routine is right
there to discover that fact. Furthermore,
for most of its life the setting of the
TCL_INTERP_DESTROYED flag has been broken.
See Feature Request 1714505 and Bug 1706140.

I'm in no mood to add something stupid to
command traces, just because the originators
of them couldn't be bothered to write correct
docs in the first place.  My intended fix
is to change the docs to match what the code
does.

This would all be harmless stupidity, except
that apparently Donal Fellows made the mistake
of believing the docs when writing TclOO,
which assumes the TCL_INTERP_DESTROYED flag
is meaningful in a command delete trace.
User Comments: dgp added on 2008-08-07 04:24:01:
Logged In: YES 
user_id=80530
Originator: YES


Fixed the attempted use of this
feature in TclOO.c.