#1034 compile warning in base.c/fio.c: ISO C forbids conversion...


While compiling SWIG on Ubuntu Linux 9.04
gcc 4.3.3
Swig 1.3.39
Python 2.6.2

It still installed, and I will work with it, but the warnings made me a little nervous.

DOH -I../Source/CParse -I../Source/Preprocessor -I../Source/Swig -I../Source/Modules -g -O2 -Wall -W -ansi -pedantic -MT DOH/base.o -MD -MP -MF $depbase.Tpo -c -o DOH/base.o DOH/base.c &&\ mv -f $depbase.Tpo $depbase.Po
DOH/base.c: In function ‘DohCall’:
DOH/base.c:938: warning: ISO C forbids conversion of object pointer to function pointer type

DOH -I../Source/CParse -I../Source/Preprocessor -I../Source/Swig -I../Source/Modules -g -O2 -Wall -W -ansi -pedantic -MT DOH/fio.o -MD -MP -MF $depbase.Tpo -c -o DOH/fio.o DOH/fio.c &&\ mv -f $depbase.Tpo $depbase.Po
DOH/fio.c: In function ‘DohEncoding’:
DOH/fio.c:51: warning: ISO C forbids conversion of function pointer to object pointer type
DOH/fio.c: In function ‘encode’:
DOH/fio.c:75: warning: ISO C forbids conversion of object pointer to function pointer type


  • Olly Betts

    Olly Betts - 2009-07-29

    ISO C says this is undefined behaviour, but the implementation is allowed to define behaviour in such cases and POSIX requires this to work since dlsym() returns a void * which is actually a function pointer. So it's ugly, but nothing to worry about (at least on platforms which conform to POSIX, which is at least all modern Unix platforms).

    The reason the warning is given is that we pass "-ansi" to gcc, which tells it to warn in such cases, so we're getting what we asked for.

    So I think either we drop "-ansi", or we arrange not to pass it for this one file, or just put up with these warnings. The only particularly useful thing -ansi does is to make // comments an error in C code, but it's all too easy to introduce them in a mixed C and C++ codebase. C99 allows it, but still not all compilers which matter support that.

    The second option would be nicest, but SWIG uses automake in a somewhat odd way, and my attempt to implement this using the technique suggested in the automake manual failed.

    The longer term plan seems to be to replace DOH with something else which would also cure this.

  • DCTodd

    DCTodd - 2009-07-30

    Thanks Olly.
    I appreciate all the detail.
    I agree that the second solution would be the best (i.e. arrange to not pass the "-ansi" flag for these two files), but it sounds like the build process might now allow that ... . easily.
    I will forge ahead with confidence that nothing is wrong!
    Thank again, David

  • William Fulton

    William Fulton - 2009-08-16
    • status: open --> closed-wont-fix
  • William Fulton

    William Fulton - 2009-08-16

    As per Olly's comments, In practice this warning is harmless and it will disappear when DOH is replaced, so for now we just put up with it.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks