Re: [PATCH 18/348] Fix -Wsahdow warnings

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Wed, 23 Nov 2011 18:20:40 +0000
> 
> On Wednesday 23 November 2011 16:40:41, Ulrich Weigand wrote:
> > Mark Kettenis wrote:
> > 
> > > > From: Andrey Smirnov <andrew.smirnov@gmail.com>
> > > > Date: Tue, 22 Nov 2011 17:25:56 +0700
> > > > Subject: [PATCH 18/39] Fix -Wshadow warnings.
> > > > 
> > > > * amd64-linux-tdep.c (amd64_canonicalize_syscall): Fix -Wshadow
> > > > 	warnings.
> > > 
> > > Why the hell does -Wshadow complain here?
> > 
> > > > -amd64_canonicalize_syscall (enum amd64_syscall syscall)
> > > > +amd64_canonicalize_syscall (enum amd64_syscall syscall_number)
> > 
> > I'd expect this is because the parameter "syscall" shadows the global
> > function declaration "syscall" provided by glibc headers:
> > 
> > /usr/include/unistd.h:extern long int syscall (long int __sysno, ...) __THROW;
> 
> Yeah, this is unfortunate because it means you trigger different 
> shadows on different hosts, or by configuring gdb differently.

Indeed.  And I'd say this means we can't add -Wshadow to the set of
default flags for compiling gdb.

> There was this gcc patch
> 
>  http://comments.gmane.org/gmane.comp.gcc.patches/244771
> 
> to stop -Wshadow from complaning about shadowing of symbols in system
> headers, but it doesn't seem to have been applied, though it was okayed.

I'd argue that -Wshadow should never warn about a local variable
shadowing a function.  There'sno chance such shadowing is
unintentional.

It seems a lot of the changes posted up until now are dealing with
that type of "conflict".  I'd really like to see those dropped from
this set.