From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13032 invoked by alias); 24 Nov 2011 04:16:32 -0000 Received: (qmail 13023 invoked by uid 22791); 24 Nov 2011 04:16:29 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Nov 2011 04:16:15 +0000 Received: by iaek3 with SMTP id k3so3339277iae.0 for ; Wed, 23 Nov 2011 20:16:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.87.227 with SMTP id bb3mr30772244igb.29.1322108174136; Wed, 23 Nov 2011 20:16:14 -0800 (PST) Received: by 10.50.186.228 with HTTP; Wed, 23 Nov 2011 20:16:14 -0800 (PST) In-Reply-To: <201111232023.pANKNcLf022983@glazunov.sibelius.xs4all.nl> References: <201111231640.pANGefc4031803@d06av02.portsmouth.uk.ibm.com> <201111231820.40486.pedro@codesourcery.com> <201111232023.pANKNcLf022983@glazunov.sibelius.xs4all.nl> Date: Thu, 24 Nov 2011 04:16:00 -0000 Message-ID: Subject: Re: [PATCH 18/348] Fix -Wsahdow warnings From: Andrey Smirnov To: Mark Kettenis Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00672.txt.bz2 On Thu, Nov 24, 2011 at 3:23 AM, Mark Kettenis wr= ote: >> From: Pedro Alves >> 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 >> > > > 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 >> > > > =A0 =A0 =A0 =A0 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. =A0And I'd say this means we can't add -Wshadow to the set of > default flags for compiling gdb. IMHO, not setting the -Wshadow variable to the default set would only be inviting for such warnings to accumulate and grow into snowball of little instances where aforementioned rule has been violated, that would require yet another 300+ patches to clean it up. Doing so would be plugging the wholes instead of fixing the problem. I'll admit you annoyed me real good when you started kicking all my toys and called them stupid, and I apologize if my behavior is childish, but now I see your argument as this: "We can't have all the pretty names on for our variables on all the platforms because of the -Wshadow, let's not use -Wshadow", maybe I'll cool down and see the merit of your argument. Now I don't. >> There was this gcc patch >> >> =A0http://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. =A0There'sno chance such shadowing is > unintentional. "There'sno chance such shadowing is unintentional." is either an assumed conclusion or an argument from incredulity both of which are logical fallacies, but even if the shadowing is always intentional I still fail to see your point. You are trying to use the name that has already been taken, since both the names of the functions and variables reside in the same namespace it is an name clash. There is, to the best of my knowledge, no means in the C language to help compiler to resolve this ambiguity and when you ask compiler to slap you for any naming ambiguities with -Wshadow you get what you asked for. Why shouldn't it be so? > It seems a lot of the changes posted up until now are dealing with > that type of "conflict". =A0I'd really like to see those dropped from > this set. > It is not a "conflict". It is a conflict. Dropping such changes would make it impossible to test wither the whole goal of the patch-set, that is building with -Wshadow enabled, has been achieved. Andrey Smirnov