This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Built-in bzero in GCC 3.0.2


 > While compiling the readline library in the latest GDB pretest 5.0.92,
 > GCC 3.0.2 prints numerous warnings like this:
 > 
 >   gcc -c -DHAVE_CONFIG_H   -I. -I. -Id:/usr/djgpp/include
 >   -DRL_LIBRARY_VERSION='"4.1"' -g -O2 readline.c
 >   In file included from rldefs.h:53,
 >                    from readline.c:54:
 >   d:/usr/djgpp/include/string.h:53: warning: conflicting types for
 > built-in function `bzero'
 > 
 > (As you see, I used the DJGPP port here.)
 > 
 > The bzero's prototype in DJGPP's string.h is this:
 > 
 >   void * bzero(void *ptr, size_t _len);
 > 
 > Could someone please tell what prototype of bzero does GCC expect?
 > More generally, how can one know what prototypes does GCC expect from
 > functions it treats as built-in?
 > 
 > Finally, assuming that modifying the system headers is not an option,
 > is there any GCC command-line option I can use to avoid this warning?
 > (I know about -fno-nonansi-builtins, but will older versions of GCC
 > swallow it without barfing?)

IIRC, gcc internally prototypes:

      void bzero();

Note the return type is "void", not "void *".  See:
http://www.opengroup.org/onlinepubs/007908799/xsh/bzero.html

Also the builtin arguments are left ambiguous so that the builtin
prototype can match any of the following from a system header:

      void bzero(void *, size_t);
      void bzero(void *, int);
      void bzero(char *, size_t);
      void bzero(char *, int);
      [...]

It does check that there are exactly two arguments, that the first one
is a pointer of some sort, and that the second argument is an integer
type of some sort.

I believe your headers are pretending bzero behaves like memset and
returns the pointer address.  This definitly conflicts with the
internal function.

Are your headers standard DJGPP of the latest release?  If so and if
we want to support it, we might silently elide nonansi builtins whose
return type doesn't match.  Not sure if this is preferred or not.

I'm open to suggestions.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]