#2211 find command fail in Tcl8.4.1/IncrTcl3.2.1

obsolete: 8.4.1
closed-out-of-date
5
2003-02-27
2003-02-26
No

1. Tcl version : 8.4.1
2. IncrTcl version : 3.2.1
3. OS Platform : Solaris 2.5
4. Problem behavior :
tclsh8.4> load libitcl3.2.so
tclsh8.4> ::itcl::class A { }; A a
tclsh8.4> ::itcl::find object a
==>>nothing returned here
And sometimes, it dumps core.
5. Expected behaviours :
should return "a"
If I do "itcl::find object ::a", it works ok.
6. Concise code and solutions :
In $INCRTCL_ROOT/itcl/generic/itcl_cmds.c file, line
707 ~ 716
707 if (forceFullNames || nsPtr
!=(Namespace*)activeNs ||
708 originalCmd != NULL) {
709
710
objPtr=Tcl_NewStringObj((char*)NULL, 0);
711 Tcl_GetCommandFullName(interp,cmd,
objPtr);
712 name
=Tcl_GetStringFromObj(objPtr,(int*)NULL);
713 } else {
714 cmdName
=Tcl_GetCommandName(interp,cmd);
715 objPtr =Tcl_NewStringObj(cmdName,
-1);
716 }

The variable "name" is used to hold the searching
result, it is correct for match the fully qualified
name(i.e, find o ::a),
but between line 714~715, when search for "find o a",
it doesn't set the "name" variable.
In the following lines ( line 721 below ), it tries to
use "name" variable, I think that is the reason for
causing the coredump.
718 Tcl_CreateHashEntry(&unique,
(char*)cmd, &newEntry);
719
720 match = 0;
721 if (newEntry && (!pattern ||
Tcl_StringMatch(name, pattern)))

This needs to be fixed, you can move line 712 to line
717 the product will work fine.

Thanks,
Christina Junru Li.

Discussion

  • Donal K. Fellows

    • status: open --> closed-invalid
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2003-02-27
    • status: closed-invalid --> closed-out-of-date
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2003-02-27

    Logged In: YES
    user_id=72656

    This is actually out-of-date as I have already corrected this
    bug in itcl anyway. If you used a recent ActiveTcl, it would
    have the correct binaries.

     

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

Sign up for the SourceForge newsletter:





No, thanks