#4423 freeIntRepProc audit

obsolete: 8.6b1.1
Don Porter

Brief discussion on chat concluded that
the freeIntRepProc of any Tcl_ObjType
ought to set the typePtr field to NULL so
that the Tcl_Obj is not left in an inconsistent

At least some freeIntRepProc's in the
core fail to meet this expectation. Search and destroy.


  • Jan Nijtmans

    Jan Nijtmans - 2009-09-14

    Agreed, but shouln't that be the responsibility of the
    TclFreeIntRep macro? Currently, a lot of TclFreeIntRep
    calls are followed by setting (objPtr)->typePtr to NULL!
    The freeIntRepProc is not supposed to be called directly,
    so doing it in TclFreeIntRep has the advantage that
    it works for freeIntRep functions outside of the core as well.

  • Don Porter

    Don Porter - 2009-09-14

    Adding it to the TclFreeIntRep macro is
    a fine idea too, but can only help the callers
    of the macro. Since the macro is private, the
    only callers ought to be within Tcl itself. For
    the sake of extensions, we still need each
    freeIntRepProc to do its own housekeeping as

    Yes, this is a gap in the interface. We ought to
    have a public routine that plays this role.

  • Don Porter

    Don Porter - 2009-09-30

    Tcl sources updated. Tk still needs a look.

  • Don Porter

    Don Porter - 2009-11-20

    Thanks for getting the bits I missed in tclEncoding.c.
    Just committed the other missed bits in tclVar.c.

    Still open for Tk.

  • Donal K. Fellows

    All fixed in Tk HEAD. Leaving to dgp to decide whether that means this item should be closed.

  • Donal K. Fellows

    • labels: --> 10. Objects
    • milestone: --> obsolete: 8.6b1.1
    • assigned_to: nobody --> dgp
    • status: open --> open-fixed
  • Don Porter

    Don Porter - 2009-11-23
    • status: open-fixed --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks