SWIG memory problems when using different USE_POINT_Z_M settings

Tamas Szekeres szekerest at GMAIL.COM
Fri Mar 16 19:38:17 EDT 2007


Steve,

How about adding this:

#ifdef USE_POINT_Z_M
%{
#ifndef USE_POINT_Z_M
#error "This module should be created and compiled with the same
USE_POINT_Z_M setting! Recreate the interface without passing
-DUSE_POINT_Z_M at the SWIG command line!"
#endif
%}
#else
%{
#ifdef USE_POINT_Z_M
#error "This module should be created and compiled with the same
USE_POINT_Z_M setting. Recreate the interface by  passing
-DUSE_POINT_Z_M at the SWIG command line!"
#endif
%}
#endif


Best regards,

Tamas

2007/2/9, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> The solution to the error being to re-Swig then, correct? If so then the
> error should
> explicitly say that. Other than that I have no objections for the 4.10
> and main branches.
>
> Steve
>
> >>> Tamas Szekeres <szekerest at GMAIL.COM> 2/8/2007 3:06:41 PM >>>
> Hi Folks,
>
> Since we are planning to do the SWIG invocation and the compilation
> independently we should  ensure to pass the same commandline
> parameters that affect the layout of the various mapserver structures.
> Here are some bugs might be related to this problem:
>
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1881
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1890
>
> Currently the only problematic option is USE_POINT_Z_M which affects
> the members of the pointObj structure. By using different
> USE_POINT_Z_M setting during the swig generation and the compilation
> the related application will candidate to suffer from memory
> corruption problems.
>
> I think it would be sufficient at least to generate an error at compile
> time
> when the SWIG was invoked with different USE_POINT_Z_M setting.
> For example we could add the followings to mapscript.i
>
>
> #ifdef USE_POINT_Z_M
> %{
> #ifndef USE_POINT_Z_M
> #error "USE_POINT_Z_M not definied!"
> #endif
> %}
> #else
> %{
> #ifdef USE_POINT_Z_M
> #error "USE_POINT_Z_M definied!"
> #endif
> %}
> #endif
>
>
> Any objections to apply such things?
>
> Best regards,
>
> Tamas
>



More information about the mapserver-dev mailing list