[Insight-developers] Swig Wrapping Warnings.

[William A. Hoffman]

Perhaps we can add some cmake stuff to downgrade the warnings
just for the Wrapping part of the dashboard.   

-Bill


At 12:48 PM 4/5/2004, Hans J. Johnson wrote:
>Bill,
>
>OK.  I'll turn these off again.  About 2 weeks ago on the ITK
>teleconference call it was requested that these compiler flags be tuned
>on so that an attempt to fix this could be made.
>
>This means that I'll have to turn the warning flags off for all of ITK,
>and not just the wrapped part.
>
>Regards,
>Hans
>
>
>On Mon, 2004-04-05 at 11:00, William A. Hoffman wrote:
>> Since swig is a moving target, and we do updates from time to time, it may
>> be best to try and turn off warning checking for the generated code.  The
>> code is either correct or it is not, fixing warnings is not really a productive
>> exercise for swig generated wrappers.  Many times the problems show
>> up because C++ use const much more than C, swig generated code usually has
>> to be able to be compiled by an ANSI C compiler, and many of the warning fixes
>> break in C, but work in C++.
>> 
>> -Bill
>> 
>> 
>> At 11:33 AM 4/5/2004, Hans J. Johnson wrote:
>> >Hello Wrapping Experts,
>> >
>> >I've been attempting to get rid of compiler warnings from CableSwig tcl
>> >wrapped code.  The first set of changes were relativly easy to make, and
>> >eliminated about 7000 warnings.  Unfortunatly there are still about 5000
>> >warnings left to go.
>> >
>> >I beleive that one fix in cable swig will get rid of them, but I've been
>> >unable to successfully figure out how to do it.  The problem is that
>> >Swig chops off all const qualifiers for any local variable that will be
>> >an lvalue.  This is OK for non-pointer (non-reference) types, because
>> >the behavior does not affect the safety of the code, or it's use.  This,
>> >however, is not the case for pointers where the const is specified
>> >before the '*'.  
>> >
>> >e.g.
>> >===================================================================================================================
>> >static int
>> >_wrap_itkLightObject_GetNameOfClass(ClientData clientData, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[]) {
>> >    (void)clientData; (void)interp; (void)objc; (void)objv;
>> >    itk::LightObject *arg1 = (itk::LightObject *) 0 ;
>> >    char *result;
>> >
>> >    if (SWIG_GetArgs(interp, objc, objv,"o:itkLightObject_GetNameOfClass self ",0) == TCL_ERROR) SWIG_fail;
>> >    if ((SWIG_ConvertPtr(objv[1], (void **) &arg1, SWIGTYPE_p_itk__LightObject,SWIG_POINTER_EXCEPTION | 0) != TCL_OK)) SWIG_fail;
>> >    try {
>> >        result = (char *)((itk::LightObject const *)arg1)->GetNameOfClass();
>> >    }
>> >    catch(std::exception &_e) {
>> >        {
>> >            SWIG_exception(SWIG_RuntimeError, const_cast<char*>(_e.what()));
>> >        }
>> >    }
>> >    Tcl_SetObjResult(interp,Tcl_NewStringObj(result,-1));
>> >    return TCL_OK;
>> >    fail:
>> >    return TCL_ERROR;
>> >}
>> >===================================================================================================================
>> >Two changes could remove the compiler warnings in the previous code snip are: 
>> >(a) change the type of result to "const char * reusult;" and change/remove the type casting in the try block.
>> >(b) use a const_cast<char *>() in the try block instead of the c-style (char *)---(const char *) may also work.
>> >
>> >I've spent a few days trying to learn the swig wrapping mechanism well enough to make these changes, but have not
>> >found a complete working solution and have not been confident that the partial solutions would not break other 
>> >wrappings.  A patch that does the first 1/2 of option (a) is attached to this e-mail.  I could not track down where
>> >the second part was being constucted.
>> >
>> >I will not be able to devote any more time to this.
>> >
>> >Sorry,
>> >Hans J. Johnson
>> >hans-johnson at uiowa.edu
>> >
>> >
>> >
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at itk.org
>http://www.itk.org/mailman/listinfo/insight-developers