From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22300 invoked by alias); 7 Sep 2005 13:23:28 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22261 invoked by uid 22791); 7 Sep 2005 13:23:18 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 07 Sep 2005 13:23:18 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1ECztU-0000xU-I6; Wed, 07 Sep 2005 09:23:16 -0400 Date: Wed, 07 Sep 2005 13:23:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] print arrays with indexes Message-ID: <20050907132316.GA3622@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20050906202018.GC1153@adacore.com> <20050906205710.GA12715@nevyn.them.org> <20050907053951.GC1540@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907053951.GC1540@adacore.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00045.txt.bz2 On Tue, Sep 06, 2005 at 10:39:51PM -0700, Joel Brobecker wrote: > > So, yes, a language method would be good. > > Ok, how about calling it la_print_array_index? The current language_defn > structure already la_printchar and la_printstr (no "_" between print and > the object name), but I think using underscores is that much clearer in > this case. > > void (*la_print_array_index) (struct value *index_value, > struct ui_file *stream, > int format, > enum val_prettyprint pretty); > > I'll then define a new LA_PRINT_ARRAY_INDEX macro > > #define LA_PRINT_ARRAY_INDEX (index_value, stream, format, pretty) \ > (current_language->la_print_array_index(index_value, stream, format, pretty)) Fine with me. > > > (gdb) set/show print array-indexes > > > > > > With a default of "off", to preserve the current behavior. > > > > I suppose we've got to :-) I'd turn it on, that's for sure. > > There is also Jim's suggestion which has some merits. I'm more of > an all or nothing kind of guy, so I prefer the approach I've chosen, > but I am flexible. I've got no strong opinions on this either way. Thresholds seem complicated as a UI. -- Daniel Jacobowitz CodeSourcery, LLC