This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 18/348] Fix -Wsahdow warnings
> 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.