This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Built-in bzero in GCC 3.0.2
- To: eliz at gnu dot org, eliz at is dot elta dot co dot il
- Subject: Re: Built-in bzero in GCC 3.0.2
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Mon, 5 Nov 2001 00:31:02 -0500 (EST)
- Cc: gcc at gcc dot gnu dot org
> 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