#1033 Named objects in function calls return additional arguments

open
nobody
tcl (60)
5
2012-12-21
2009-07-24
No

When a C-function with return type void is called which accepts a reference to a class, the return list has an additional argument, when it is called with a named object as opposed to a pointer:

Assume a class s and a function void change_s(s&)

(swigbug) 56 % s news 120
_e0db3301_p_s
(swigbug) 57 % change_s [new_s cget -this]
(swigbug) 58 % change_s new_s
_10a03301_p_s

While this is harmless with real void functions, it becomes problematic when the function returns by a pointer:
void return_by_typemap(s& the_s, int *OUTPUT)

(swigbug) 59 % return_by_typemap [new_s cget -this]
5
(swigbug) 60 % return_by_typemap new_s
_10a03301_p_s 5
(swigbug) 61 % 95-88-123-251-dynip:swigbug chris$

The problem is, that interp->result is not cleaned after the conversion in SWIG_Tcl_ConvertPtrFromString

Discussion

  • Christian Gollwitzer

    SWIG interface file for a class that demonstrates the bug

     
  • Christian Gollwitzer

    Makefile for Mac OSX

     
  • Christian Gollwitzer

    Patch for tclrun.swg that removes the argument

     
  • Christian Gollwitzer

    The patch partly solves the problem. After the conversion of a named object, Tcl_ResetResult() is called.

    But I question the method in general. Currently we simply eval the command with the arguments cget -this. In case someone supplies any proc which eats two arguments, this can result in very strange side effects.
    (swigbug) 49 % load ptrbug.dylib
    dlsym(0x13349f0, Ptrbug_SafeInit): symbol not founddlsym(0x13349f0, Ptrbug_Unload): symbol not founddlsym(0x13349f0, Ptrbug_SafeUnload): symbol not found
    (swigbug) 50 % s news 10
    _20453301_p_s
    (swigbug) 51 % proc echo {args} {puts [concat $args]}
    (swigbug) 52 % return_by_typemap echo
    cget -this
    TypeError in method 'return_by_typemap', argument 1 of type 's &'

    Instead of calling, could we store the object names in a global hash table?

     
  • Christian Gollwitzer

    OK, I think I've found the solution. Using Tcl_GetCommandInfo, we can look if the given string is a command associated with SWIG_Tcl_MethodCommand. Then we can directly extract the pointer and its type information from the ClientData. The new patch realizes this.

    Open questions
    1) What is this DISOWN-thingy good for?
    2) Is the type info extracted correctly from swig_instance
    3) any other bugs???

     
  • Christian Gollwitzer

    Hmm, what's up? No comment?

     
  • William Fulton

    William Fulton - 2009-08-27

    There isn't anyone maintaining the TCL module at the moment. I'll consider the patch for inclusion if you test your patch against the test-suite with no regressions and you include a runtime test for the li_typemaps.i testcase, in otherwords take one of the li_typemaps_runme.* runtime tests and port to TCL. If you need any help running the test-suite contact me.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks