This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Clean-up C's builtin function type matching.
On 21-Jul-2003, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Sun, 20 Jul 2003, Roger Sayle wrote:
> > Continuing in my current run of improvements to GCC's builtin function
> > handling, the following patch tidies up the fuzzy type checking code
> > for builtin functions in the C front-end's duplicate_decls.
>
> That's really a coincidence, seeing this patch after just discussing a
> related issue with the FreeBSD guys who just updated their system compiler
> to GCC 3.3 and experienced a regression. ;-)
>
> Consider the following program:
>
> extern int exp;
>
> int main() {
> int sin=1;
> return sin+exp;
> }
This program does not conform to the C standard.
The name "exp" is reserved for use as an identifier with external linkage.
A diagnostic is not required, but would certainly be a good idea.
> Plain gcc issues
> x.c:1: warning: built-in function `exp' declared as non-function
> and gcc -Wshadow issues
> x.c:1: warning: built-in function `exp' declared as non-function
> x.c: In function `main':
> x.c:4: warning: declaration of `sin' shadows a global declaration
> <built-in>:0: warning: shadowed declaration is here
> all of which I have been told are wrong as long as <math.h> hasn't been
> #included.
The warnings about `exp' are definitely justified, even if <math.h>
hasn't been included, since the program fails to conform to the C standard.
The warnings about `sin' are a bit more debatable. Arguably it is bad
style to use the name of a standard C function as the name of a local
variable, if the relevant header file isn't included. So whether this
change to the behaviour of -Wshadow is a regression or a progression is
in the eyes of the beholder.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.