SWIG mapscript critical problems!!!

[Daniel Morissette]

Tamas Szekeres wrote:
> 
> I cannot decide whether these issues apply to the PHP mapscript 

Here is my assessment of the PHP MapScript situation:

> 
> 1. Constructing layers from scratch (not declared by map file) is a common
> situation for this issue.
> We have the following constructors to create a layer or the subsequent
> objects dynamically:
> 
> layerObj(mapObj map)
> classObj(layerObj layer)
> styleObj(classObj parent_class)
> 
> A new object is created with swigCMemOwn=true by default. If one gives not
> null parameter for these constructors. The object (referenced by the
> parameter) will take the ownership of the
> memory referenced by the swigCPtr of the newly created object. Therefore
> swigCMemOwn should be set to false (the object should be "disowned" in the
> swig terminology) The current C# fix does exactly this by adding for
> example:
> 
> %typemap(csconstruct, excode=SWIGEXCODE) layerObj(mapObj map) %{:
> this($imcall, true) {
>   if (map != null) this.swigCMemOwn = false;$excode
> }
> %}
> 


This is not an issue in PHP MapScript because the layerObj, classObj and 
styleObj constructors do not accept a NULL parent reference. e.g. 
passing a NULL map reference to ms_newLayerObj() would trigger an error 
right away and abort script execution.


> 2. Passing objects as parameters is the next area where improper ownership
> may occur.
> If a wrapped C struct has another struct or pointer to a struct that is not
> readonly implies to create setter functions that have another object as a
> parameter.
> If the outer struct takes the ownership of this struct (and will free it
> later) the object should be "disowned" by swig that is: swigCMemOwn should
> be set to false in the C# wrapper object.
> 
> The more complicated case is if the inner element is a struct itself. SWIG
> will make a raw copy of the struct, however the referenced inner elements of
> the internal struct (char* represented strings for example) are not copied.
> 
> In my opinion it is the best to avoid such a situation mentioned before and
> eliminate these elements from the interface if the functionality can be
> achieved in other ways.
> If the usage of the interface element is inevitable proper handling of the
> object ownership is needed.
> It must be noted that how an object handles an inner object is somewhat
> apllication specific so these issues cannot be considered as a bug for the
> SWIG interface generator.
> 
> 

In PHP MapScript, setting class members is always done via explicit 
set() methods which should handle referencing the right way already. We 
required the use of set() methods because in the early days of PHP there 
was no way to get a callback when a class member was set (to update the 
internal refs to the C structs), so we ended up implementing set() 
methods on all objects to work around that issue... and that protected 
us from this possible pitfall that you just discovered in SWIG MapScript.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/