[Insight-developers] Re: a problem with cable swig cvs

[Brad King]

Gaëtan Lehmann wrote:
> I see that you have added the gcc 4.2 support in cableswig cvs. That's
> great :-)
> I'll test it soon.
> 
> However, I noticed a new problem with cableswig cvs. The python typemaps
> are broken, I think because of a very simple problem: the numbers in the
> template name get an additionnal "u" compared to the previous version.
> It seem to break the comparison of types produced by the swig
> "$descritor()" command.
> 
> For example, itk::Image< unsigned short, 3 > is now translated in:
> 
>   SWIGTYPE_p_itk__ImageTunsigned_short_3u_t
> 
> but it was:
> 
>   SWIGTYPE_p_itk__ImageTunsigned_short_3_t
> 
> with cableswig 3.4
> 
> The .xml files also have that additional "u" (as well as the .idx
> files), so it seem that this change in the behavior comes from gccxml.
> 
> 
> I'm not sure what is the best way to proceed: restore the previous
> behavior in gccxml, or patch cableswig to make it produce that
> additionnal "u", as gccxml does?

This change came from GCC 4.2's internals.  When specifying an unsigned
integer literal it now correctly gives it the 'u' suffix to make the
literal the correct type.  The behavior from gccxml is not wrong.

The question is why does this change break swig.  It should always see
the name with the 'u' in place now.  Can you send an example python
script that does not work with the new wrappers?

Thanks,
-Brad