From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3359 invoked by alias); 30 Nov 2011 14:59:59 -0000 Received: (qmail 3349 invoked by uid 22791); 30 Nov 2011 14:59:58 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Nov 2011 14:59:40 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAUExOh4023925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 09:59:24 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pAUExNqm008966; Wed, 30 Nov 2011 09:59:24 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pAUExMDO024030; Wed, 30 Nov 2011 09:59:22 -0500 From: Tom Tromey To: Andrey Smirnov Cc: Joel Brobecker , gdb-patches Subject: Re: [PATCH 18/348] Fix -Wsahdow warnings References: <201111231640.pANGefc4031803@d06av02.portsmouth.uk.ibm.com> <201111231820.40486.pedro@codesourcery.com> <201111232023.pANKNcLf022983@glazunov.sibelius.xs4all.nl> <20111124220057.GU13809@adacore.com> <20111125142615.GV13809@adacore.com> Date: Wed, 30 Nov 2011 14:59:00 -0000 In-Reply-To: (Andrey Smirnov's message of "Wed, 30 Nov 2011 09:47:47 +0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/msg00844.txt.bz2 >>>>> "Andrey" =3D=3D Andrey Smirnov writes: Andrey> I know I probably should go to GCC mailing list and ask that questi= on Andrey> there, but anyways, would this patch cause gcc to stop generating t= he Andrey> warning about local variable shadowing global one from system heade= rs? Yeah, that's what it does. Andrey> I hope that kinds of shadowing would still be detectable even with = this Andrey> patch applied. Why is that? I do think the GCC patch could probably be better. That is, I think a slightly different rule would be an improvement, something like "generally do not warn about shadowing things declared in system headers, except if a local function pointer variable shadows a system function". That would eliminate the potential for some kinds of bugs. Tom> Still, what it does is prevent the warning when shadowing something fr= om Tom> a system header. =C2=A0This seems decent to me and in particular will,= I Tom> think, largely address Mark's concerns. Andrey> It would pretty much solve that problem, yes, but still it would Andrey> divide patch submitters into two groups those who have newest gcc a= nd Andrey> -Wshadow enabled by default, and those who don't. And the people Andrey> without -Wshadow enabled compilers would be, on occasion, breaking = the Andrey> build because they have no means to check for -Wshadow caused error= s. Andrey> I hope I missing something and it is not the case, but that how the Andrey> things seems to me now. Yes, I think it would result in some periodic breakage until the newer GCC is widely distributed. I'm willing to put up with that. We already put up with it, in a way, due to other GCC differences... see the uninitialized variable patches or FORTIFY_SOURCE patches that go in from time to time. If the configury part is set up properly, then this warning will simply auto-enable for people when they upgrade GCC. So, it isn't like we'll just forget about it; more like at some point we'll all be joining in :) Tom