From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26744 invoked by alias); 25 Nov 2011 12:03:49 -0000 Received: (qmail 26734 invoked by uid 22791); 25 Nov 2011 12:03:48 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Nov 2011 12:03:32 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LV700C00TDCTP00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 25 Nov 2011 14:02:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.50.247]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LV700CAXTGVBV80@a-mtaout22.012.net.il>; Fri, 25 Nov 2011 14:02:56 +0200 (IST) Date: Fri, 25 Nov 2011 12:03:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 18/348] Fix -Wsahdow warnings In-reply-to: <20111124220057.GU13809@adacore.com> To: Joel Brobecker Cc: andrew.smirnov@gmail.com, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83hb1s8l5c.fsf@gnu.org> References: <201111231640.pANGefc4031803@d06av02.portsmouth.uk.ibm.com> <201111231820.40486.pedro@codesourcery.com> <201111232023.pANKNcLf022983@glazunov.sibelius.xs4all.nl> <20111124220057.GU13809@adacore.com> 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/msg00694.txt.bz2 > Date: Thu, 24 Nov 2011 14:00:57 -0800 > From: Joel Brobecker > Cc: Mark Kettenis , gdb-patches > > I mean, I understand that "index" might be part of a system's > include. But "block_found" (or was it "found_block") seems quite > surprising. If it surprised you, it means -Wsahdow did its job well. IOW, it's easy to avoid well-known names like `printf' or `strchr'. It's the not-so-well-known names that give you hell and high water. > Add the fact that includes and compiler vary from system to system, > and we're not sure that once clean on one machine, it'll be clean > everywhere else. But this is true of any other non-trivial piece of our code. E.g., if you declare a variable `long' expecting it to be a 64-bit type, this will break on MS-Windows, and you will never no until you actually try such a compilation. In general, we have no bullet-proof way of making sure our code works on all supported platforms, except by actually compiling it on those platforms. That's why platforms which lose their area maintainers bit-rot quite quickly. This compiler switch doesn't change this situation in any way. > All of this to fix warnings that, as far as I could tell for the > most part, did not indicate an actual bug in the code. It's a bug waiting to happen, though. That it didn't happen yet is just sheer luck.