#3054 Tcl_FindCommand: bogus comment?

obsolete: 8.5b2
closed-fixed
8
2007-10-27
2005-02-01
Don Porter
No

A comment following the "name"
argument to Tcl_FindCommand
claims:

"If it starts with "::", will be looked
up in global namespace."

Since custom resolvers are given
first crack at the resolving task,
and since they are apparently
free to resolve names matching
::* however they like, I think
this comment is false.

Discussion

  • Don Porter

    Don Porter - 2005-02-01

    Logged In: YES
    user_id=80530

    Completing the thought, if
    a Tcl_FindCommand() caller
    wants to force resolution in
    the global namespace, it should
    use the TCL_GLOBAL_ONLY
    flag to accomplish that.

     
  • Don Porter

    Don Porter - 2005-02-02

    Logged In: YES
    user_id=80530

    there may be a lurking
    inconsistency here with
    Tcl_GetCommandFromObj()
    where commands beginning
    with "::" *do* get special treatment.

     
  • Don Porter

    Don Porter - 2005-02-02

    Logged In: YES
    user_id=80530

    ok, so I'm closing in on
    the opinion that the comment
    *ought* to be true, and the
    bug here is that the current
    implementation of
    Tcl_FindCommand allows
    custom resolvers to
    interpret a fully qualified
    command name to mean something
    other than its plain meaning.
    It appears this possibility is
    inconsistent with assumptions
    in other parts of Tcl.

     
  • Don Porter

    Don Porter - 2005-08-29
    • priority: 5 --> 7
     
  • miguel sofer

    miguel sofer - 2007-09-13
    • milestone: 455018 --> 723147
    • priority: 7 --> 8
     
  • miguel sofer

    miguel sofer - 2007-10-27
    • milestone: 723147 --> obsolete: 8.5b2
    • status: open --> closed-fixed
     
  • miguel sofer

    miguel sofer - 2007-10-27

    Logged In: YES
    user_id=148712
    Originator: NO

    No inconsistency there: SetCmdNameFromAny calls Tcl_FindCommand to determine the command.

    What may be problematic is that the cmdName stores the global ns as the origin of the search for FQ names. This would cause buggy behaviour if
    (a) a namespace ns has a resolver that redirects FQ names
    (b) an FQ command ::cmdA is searched starting from ns, and resolved to (say) ::B
    (c) ::cmdA is resolved starting from elsewhere; the cached pointer to ::B will be used

    I agree that eventually the "correct" behaviour may be for FQ names to bypass all resolvers. Chose a "conservative" fix for now: insure that Tcl_FindCommand starts the search for FQ commands in the global ns. The difference is that resolvers on the global namespace or interp wide resolvers will be called.

    Tests show that itcl, xotcl and TclOO do not mind.

     

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks