From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23672 invoked by alias); 15 Nov 2008 19:02:00 -0000 Received: (qmail 23637 invoked by uid 22791); 15 Nov 2008 19:02:00 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 15 Nov 2008 19:01:22 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DD9162A9627; Sat, 15 Nov 2008 14:01:20 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id umfGXWthtB3h; Sat, 15 Nov 2008 14:01:20 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 893C12A9626; Sat, 15 Nov 2008 14:01:20 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 615BEE7ACD; Sat, 15 Nov 2008 11:01:18 -0800 (PST) Date: Sun, 16 Nov 2008 08:20:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: Eli Zaretskii , msnyder@vmware.com, gdb-patches@sourceware.org Subject: Re: [RFA] [patch] 'info symbol' to print more info Message-ID: <20081115190118.GL12802@adacore.com> References: <20081114204617.A4A533A6B15@localhost> <491DF12A.5090903@vmware.com> <8ac60eac0811141406h4bb126c0sbd898e7d612f46dd@mail.gmail.com> <491E08BF.2050609@vmware.com> <8ac60eac0811150842x78206050t435c6f8c89ddc8ae@mail.gmail.com> <8ac60eac0811151022w13df6899v13bb321ee08aae09@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0811151022w13df6899v13bb321ee08aae09@mail.gmail.com> User-Agent: Mutt/1.4.2.2i 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: 2008-11/txt/msg00397.txt.bz2 > But here, the message is already built up from 3 separate conditions, > and I am adding one more. What you are proposing then leads to a > chain of 16 if/then/else clauses. I don't think that's really > appropriate ... I haven't looked very closely at the details of the patch since Michael and Eli already did, so I can't comment on the exact number of if branches. But, generally speaking, we just don't have much choice if we want to support i18n well. That being said, I agree that 16 branches is a large number, and perhaps we should let go of some of them. For instance, there was this discussion about not printing the name of the objfile if MULTI_OBJFILE_P. If we get rid of that, does it reduce the number of cases? The idea itself is nice, but perhaps code simplicity is more important in this case. Are there any other cosmectic features that we can get rid of to reduce the number of cases further? -- Joel