#1279 unexpected conflicting types error

OTHER
closed
nobody
gcc (462)
invalid
Behaves_as_Documented
2014-10-05
2009-03-27
jpmague
No

I use the Ubuntu version og minGW gcc to cross compile.

Here is the output of "i586-mingw32msvc-gcc bug.c" :
bug.c:4: error: conflicting types for ‘f’
bug.h:1: error: previous declaration of ‘f’ was here

Here is the output of "i586-mingw32msvc-gcc -v bug.c" :
Using built-in specs.
Target: i586-mingw32msvc
Configured with: /build/buildd/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs
Thread model: win32
gcc version 4.2.1-sjlj (mingw32-2)
/usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1 -quiet -v bug.c -quiet -dumpbase bug.c -mtune=pentium -auxbase bug -version -o /tmp/ccWZc9YG.s
ignoring nonexistent directory "/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include
End of search list.
GNU C version 4.2.1-sjlj (mingw32-2) (i586-mingw32msvc)
compiled by GNU C version 4.2.3 20071210 (prerelease) (Ubuntu 4.2.2-4ubuntu2).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9f7339889766358351a8c487565f111d
bug.c:4: error: conflicting types for ‘f’
bug.h:1: error: previous declaration of ‘f’ was here

Discussion

  • jpmague

    jpmague - 2009-03-27
     
  • jpmague

    jpmague - 2009-03-27
     
  • jpmague

    jpmague - 2009-03-27

    There are to way to avoid the error:
    #1. Change the include order (ie stdlib.h before bug.h)
    #2. Change the name of the argument of the function (e.g. 'n' instead of errno)

     
  • Keith Marshall

    Keith Marshall - 2009-03-27

    My gut reaction is to ask why you are bothering to report what you consider to be a bug in *Ubuntu's* i586-mingw32msvc to us, (and what the heck is mingw32msvc anyway; the canonically correct host doublet is i586-mingw32)? We have our own officially supported cross-compiler build, and we do not support theirs.

    However, in this case, I can reproduce identically the same behaviour with our official mingw32-gcc, and I would hesitate to call it a bug.

    If you inspect preprocessed source, as our bug reporting guidelines request, you can see clearly what is happening. "errno" is a global symbol, required by the ISO C standard, and designated a "reserved identifier". To make it available from the Microsoft runtime library, we implement "errno" as a preprocessor define, (present in stdlib.h, because MSDN requires that), which maps "errno" to a DLL accessor function, to get or set the value of the global data item; (the ISO C standard sanctions such an implementation). In your example, that define isn't in scope when you prototype f(), but it is when you define the implementation, hence the inconsistency between prototype and implementation.

    The bug here is in your sample code; you are misusing a reserved identifier.

     
  • Keith Marshall

    Keith Marshall - 2009-03-27
    • milestone: --> Behaves_as_Documented
    • status: open --> closed-invalid
     
  • Earnie Boyd

    Earnie Boyd - 2013-01-21
    • status: closed-invalid --> closed
    • resolution: --> invalid
    • category: --> Behaves_as_Documented
    • milestone: Behaves_as_Documented --> OTHER
     

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