[Swig-devel] Scilab pointer type-checking

[Bryan Gardiner]

Hi folks,

I've discovered a limitation in SWIG's support of Scilab as described
in the bug at [1]: SWIG passes raw C++ pointers to Scilab and thus
doesn't preserve type information needed to make overloading work
when the overloads differ in the object pointer types they accept.

I have a preliminary patch (attached, updated slightly from [2]) to
bundle raw pointers with a swig_type_info* in a SwigSciWrapperObj
similar to SwigPyObject, but the object ownership is unclear to me so
I'm not sure whether this is correct, and would really appreciate some
review.

SwigScilabPtrFromObject is called to return a pointer to Scilab at the
end of a wrapper function, so I've made it create a new
SwigSciWrapperObj. Does it need to be up to the Scilab runtime to
manage the lifetime of this wrapper? I'm not sure the Scilab FFI
supports automatic management for this. Currently I only delete
wrappers when delete is called on the underlying object (which calls
SwigScilabPtrToObject with SWIG_POINTER_DISOWN), which I'm pretty sure
is leaking.

I'm also unsure what to do in SwigScilabPtrToObject (argument parsing)
when SWIG_TypeCast returns with SWIG_CAST_NEW_MEMORY set. I see the
note in git/CHANGES, but what is being allocated here?

Thanks for any help you can provide, and Happy New Year!

Bryan

[1] https://github.com/swig/swig/issues/534
[2] https://github.com/swig/swig/pull/552

[William S Fulton]

Post by Bryan Gardiner
Hi folks,
I've discovered a limitation in SWIG's support of Scilab as described
in the bug at [1]: SWIG passes raw C++ pointers to Scilab and thus
doesn't preserve type information needed to make overloading work
when the overloads differ in the object pointer types they accept.
I have a preliminary patch (attached, updated slightly from [2]) to
bundle raw pointers with a swig_type_info* in a SwigSciWrapperObj
similar to SwigPyObject, but the object ownership is unclear to me so
I'm not sure whether this is correct, and would really appreciate some
review.
SwigScilabPtrFromObject is called to return a pointer to Scilab at the
end of a wrapper function, so I've made it create a new
SwigSciWrapperObj. Does it need to be up to the Scilab runtime to
manage the lifetime of this wrapper? I'm not sure the Scilab FFI
supports automatic management for this. Currently I only delete
wrappers when delete is called on the underlying object (which calls
SwigScilabPtrToObject with SWIG_POINTER_DISOWN), which I'm pretty sure
is leaking.
I'm also unsure what to do in SwigScilabPtrToObject (argument parsing)
when SWIG_TypeCast returns with SWIG_CAST_NEW_MEMORY set. I see the
note in git/CHANGES, but what is being allocated here?
Thanks for any help you can provide, and Happy New Year!
Bryan
[1] https://github.com/swig/swig/issues/534
[2] https://github.com/swig/swig/pull/552

Hi Bryan,
Simon Marchetto is the Scilab maintainer and will need to review the patches.

I can tell you about SWIG_CAST_NEW_MEMORY though. This is used for the
shared_ptr support. If the underlying stored pointer is a
shared_ptr<Derived>* and a shared_ptr<Base>* is required, the type
cast function creates new memory to convert between these types and
SWIG_CAST_NEW_MEMORY indicates is then used to indicate that the new
memory needs deleting. This is different to the usual case when you a
pointer is simply cast to another pointer type. I'm not sure about
scilab, but if you debug the python li_boost_shared testcase you can
see this. SWIG_CAST_NEW_MEMORY is used in the shared_ptr typemaps.

William

------------------------------------------------------------------------------