#385 removal of exported internals from tclInt.h (EXTERN macro)

closed-fixed
Jan Nijtmans
5
2011-10-13
2004-10-27
David Gravereaux
No

This patch report is to contain discussion of the
current scope problem with regards to internal
functions that are being exported by-way of improper
use of the EXTERN macro within tclInt.h.

There will be a patch file shortly.

Discussion

1 2 3 > >> (Page 1 of 3)
  • Logged In: YES
    user_id=7549

    initial patch uploaded.

     
  • Logged In: YES
    user_id=7549

    exports reduced to 739 from 951 saving us from exporting 212
    functions that weren't "blessed" by being in the Stubs table.

     
  • Logged In: YES
    user_id=7549

    whoop! My mistake. exports count is 706. The savings is 245.

     
  • Logged In: YES
    user_id=7549

    Notes to self:

    1) tcl.h(2330) Tcl_Main is not in the Stubs table, but is
    exported. What to do?.. Probably drop it into tcl.decls
    like it should have always been.

    2) unix\tclXtNotify.c(97) TclSetAppContext is being exported
    from there.. hmm.. No clue what should be done.

    3) unix\tclLoadShl.c(22) yet another reason to rename EXTERN
    to TCL_EXTERN, but this time do it the right way.

     
  • Logged In: YES
    user_id=79902

    Tcl_Main must not go in the stubs table, but it must be a
    public API function of the core. It's only ever intended for
    code that is linked against tcl.dll (add your version number
    of choice) directly.

    (I believe we've been through the loop on that item many
    times before.)

     
  • Logged In: YES
    user_id=7549

    new patch with stuff I forgot and Tcl_Main moved to the
    public Stubs table.

     
  • Logged In: YES
    user_id=7549

    Actually, no we haven't discused this before.

    Placing Tcl_Main in the Stub also exports from the dll, so
    it is the same.

    It just so happens to have a vector in the table. Whether
    an extension is to use it or not is neglegable. True, it
    doesn't make sense from the point-of-view of an extension,
    but people also use Stubs with applications. Granted,
    without having interp to request it's table, it isn't
    obvious. People who LoadLibrary"tclXX.dll), then
    GetProcAddress(hTcl, "Tcl_CreateInterp") then Tcl_InitStubs
    can get the table that way. I can show you examples in code
    if you prefer.

    Also search google for c.l.t. posts by Paul Duffin around
    the `99 timeframe where someone showed him the usefulness of
    Tcl_Main being in the table.

     
    • summary: removal of exported privates from tclInt.h (EXTERN macro) --> removal of exported internals from tclInt.h (EXTERN macro)
     
  • Logged In: YES
    user_id=7549

    Lets be clear on scope again. Here are the levels worded a
    bit differently:

    1) Public functions in the Stubs table.
    - Full privilege, the exported API.
    - ex. Tcl_CreateInterp

    2) Private functions in the Stubs table.
    - available to the user of the API and exported, but no
    guarantee across versions as they could change.
    - ex. TclDeleteCompiledLocalVars

    3) Internal functions and variables shared across the
    sources, but not exported.
    - no access from the outside.
    - ex. TclFinalizeCompExecEnv

    4) File scope variables and functions not intended to be
    accessed outside the source file they are declared in.
    - no access from the outside.
    - ex. BuildCommandLine from win/tclWinPipe.c and struct
    ThreadSpecificData found in almost every source file.

    Lets call these problem functions the 'internal' (#3) ones
    and the exported ones from tclInt.decls the 'private' #2
    ones. All functions that fit class#3 need to have their
    accidental exporting removed.

     
  • I be ohh so crazy in my use of Stubs.

     
    Attachments
  • Logged In: YES
    user_id=7549

    dkf: here's some fun.. Have a look at crazy.c I just
    attached. If one starts that "shell" with the path to
    tcl85.dll built by this patch, Tcl_Main has an entry in the
    table and Stubs works. I could have attained the address to
    Tcl_Main with GetProcAddress, but I'm trying to make a point
    that Stubs should be for eveyone and no publics should escape.

    Even seen anyone use Stubs like that?

     
  • Logged In: YES
    user_id=7549

    here's another done GUI flavor. No main window is present
    as I don't feel like merging event loops by calling
    Tcl_DoOneEvent(TCL_DONT_WAIT) from a WM_IDLE and WM_TIMER
    and the nastiness it gets into. Imagine for a moment that
    Tcl is being run in a thread with async console reading
    seperate from the GUI's message pump and is a full featured
    GUI in MFC or wxWindows.

    AllocConsole() from a GUI app is pretty neet, eh?

     
  • more Stubs oddness

     
    Attachments
  • Logged In: YES
    user_id=79902

    If Tcl_Main() was stubbed, apps would be unable to call it
    without first initializing the stub table reference. This
    breaks existing users of the API, for whom the call to it is
    probably the only thing they have in their main() at the moment.

    Your examples are all very well, but they run smack into the
    fact that current users of Tcl_Main() would be significantly
    negatively impacted for no gain that they'd see. It's very
    much an exception!

    Assigning to someone else to argue with you that stubbing
    Tcl_Main is a bad idea...

     
    • assigned_to: davygrvy --> dgp
    • labels: --> 310718
     
  • Don Porter
    Don Porter
    2004-10-28

    Logged In: YES
    user_id=80530

    dkf's last comment should
    be conclusive on the point
    that adding Tcl_Main() to
    the public stub table is an
    interface change, needing a TIP,
    and should be out of scope in
    this bug-fixing patch.

    I'll save my arguments for when
    that arrives. ;)

    Thanks for the work cleaning up
    the internal stuff though!

    Passing control to another pair
    of eyeballs.

     
  • Don Porter
    Don Porter
    2004-10-28

    • assigned_to: dgp --> kennykb
     
  • Logged In: YES
    user_id=7549

    Actually, it isn't an interface change at all. The scope is
    unchanged being as public as it was before.

     
  • Don Porter
    Don Porter
    2004-10-28

    Logged In: YES
    user_id=80530

    check the Tcl_Main() documentation.

    Tcl_Main() is explicitly not available
    to extensions. It's also not thread-safe,
    so unsuitable for stub-based access.

     
  • Logged In: YES
    user_id=7549

    But extension aren't the only thing tcl is used for.

     
  • Joe English
    Joe English
    2004-10-28

    Logged In: YES
    user_id=68433

    > Actually, it isn't an interface change at all. The scope is
    > unchanged being as public as it was before.

    It's a big change at the source level: after #include
    <tcl.h>, the symbol 'Tcl_Main' would be a macro that
    dereferences a (unititialized) function pointer, instead of
    a public function name.

    This would cause catastrophic failures for nearly all
    current users of Tcl_Main().

     
  • Logged In: YES
    user_id=7549

    dkf> If Tcl_Main() was stubbed, apps would be unable to call it
    dkf> without first initializing the stub table reference.

    Untrue! Only if they were using the Stub interface.
    implicit linking is as normal by not specifying
    USE_TCL_STUBS. Just like all other exported functions. The
    standard shells are not build with -DUSE_TCL_STUBS.

    dkf> This breaks existing users of the API, for whom the
    call to
    dkf> it is probably the only thing they have in their main()
    at the
    dkf> moment.

    Again, untrue! The only difference is that Tcl_Main is
    defined to (tclStubsPtr->tclMain) for when USE_TCL_STUBS is
    defined. It never never had an entry in the table before.
    Without USE_TCL_STUBS, it is as it was regarding visibility.

     
  • Logged In: YES
    user_id=7549

    jenglish: show me an example in code where someone builds a
    shell and has defined USE_TCL_STUBS, but expects Tcl_Main to
    be linked implicitly. IOW, Tcl_Main is through implicit
    linkage and their Tcl_Init is by way of the Stubs table.

     
  • mixing requires the import library

     
    Attachments
  • Logged In: YES
    user_id=7549

    jenglish: build crazyALT1.c against 8.4 and you'll see at
    link-time you need to specify tcl84.lib (the import library)
    along with tclstub84.lib.

    By Tcl_Main being the "bad apple" in the basket, and
    requires the import library, the version indepedence that
    Stubs allows us was destroyed. Though users of this style
    probably got smart and probably switched to a manual
    LoadLibrary and got the address to Tcl_Main with
    GetProcAddress when looking for Tcl_CreateInterp, too. I'd
    do that given that the current "no access" is ilfounded when
    Stubs was only thought to used for extension only.

     
1 2 3 > >> (Page 1 of 3)