X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Subject: Re: conflicting types for bzero (gcc303) From: Tim Van Holder To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com, ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Feb 2002 11:45:45 +0100 Message-Id: <1013078746.9713.25.camel@bender.falconsoft.be> Mime-Version: 1.0 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 2002-02-07 at 10:49, Eli Zaretskii wrote: > > On 7 Feb 2002, Tim Van Holder wrote: > > > The point is that gcc only complains if you force it to use our own > > headers by explicitly listing -I$DJDIR/include on the command line. > > No, it will complain if you compile a program that includes string.h and > calls bzero/bcopy, even if you don't use any -I switches. Really? $ cat foo.c #include void foo() { bzero (NULL, 0); } $ i586-pc-msdosdjgpp-gcc -v Reading specs from /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/specs Configured with: ../gcc/configure --target=i586-pc-msdosdjgpp --prefix=/opt/gcc3 Thread model: single gcc version 3.0.1 20010618 (prerelease) $i586-pc-msdosdjgpp-gcc -S foo.c -o /dev/null -Wall -v Reading specs from /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/specs Configured with: ../gcc/configure --target=i586-pc-msdosdjgpp --prefix=/opt/gcc3 Thread model: single gcc version 3.0.1 20010618 (prerelease) /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=1 -D__MSDOS__ -D__GO32__ -D__MSDOS__ -D__GO32__ -Asystem=msdos -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Wall -remap -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -DMSDOS -DGO32 -imacros /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/../../../../i586-pc-msdosdjgpp/lib/../include/sys/version.h foo.c -quiet -dumpbase foo.c -Wall -version -o /dev/null GNU CPP version 3.0.1 20010618 (prerelease) (cpplib) (80386, BSD syntax) GNU C version 3.0.1 20010618 (prerelease) (i586-pc-msdosdjgpp) compiled by GNU C version 3.0 20010514 (prerelease). #include "..." search starts here: #include <...> search starts here: /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/include /opt/gcc3/i586-pc-msdosdjgpp/sys-include /opt/gcc3/i586-pc-msdosdjgpp/include End of search list. $i586-pc-msdosdjgpp-gcc -S foo.c -o /dev/null -Wall -I /opt/gcc3/i586-pc-msdosdjgpp/sys-include -v Reading specs from /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/specs Configured with: ../gcc/configure --target=i586-pc-msdosdjgpp --prefix=/opt/gcc3 Thread model: single gcc version 3.0.1 20010618 (prerelease) /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/cc1 -lang-c -v -I /opt/gcc3/i586-pc-msdosdjgpp/sys-include -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=1 -D__MSDOS__ -D__GO32__ -D__MSDOS__ -D__GO32__ -Asystem=msdos -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Wall -remap -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -DMSDOS -DGO32 -imacros /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/../../../../i586-pc-msdosdjgpp/lib/../include/sys/version.h foo.c -quiet -dumpbase foo.c -Wall -version -o /dev/null GNU CPP version 3.0.1 20010618 (prerelease) (cpplib) (80386, BSD syntax) GNU C version 3.0.1 20010618 (prerelease) (i586-pc-msdosdjgpp) compiled by GNU C version 3.0 20010514 (prerelease). ignoring duplicate directory "/opt/gcc3/i586-pc-msdosdjgpp/sys-include" #include "..." search starts here: #include <...> search starts here: /opt/gcc3/i586-pc-msdosdjgpp/sys-include /opt/gcc3/lib/gcc-lib/i586-pc-msdosdjgpp/3.0.1/include /opt/gcc3/i586-pc-msdosdjgpp/include End of search list. In file included from foo.c:1: /opt/gcc3/i586-pc-msdosdjgpp/sys-include/string.h:53: warning: conflicting types for built-in function `bzero' This is with gcc 3.0.1 on Linux, but I see the same behaviour with gcc 3.0.[23] on WinXP. > > If you don't do so, I assume it uses its own private version. > > We cannot tell users not to use string.h in their programs. Having > prototypes visible to the compiler is a good programming practice; -Wall > flags functions without prototypes, so if they use -W* switches, they > will have a warning one way or the other. > > We should fix this. I wasn't saying we don't need to fix it in our headers. I was merely saying that the specific case reported by Juan Manuel could be solved by editing the Makefile or by using specific options for configure.