From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14028 invoked by alias); 18 Sep 2005 19:19:51 -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 14018 invoked by uid 22791); 18 Sep 2005 19:19:47 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 18 Sep 2005 19:19:47 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EH4hT-00076q-V0; Sun, 18 Sep 2005 15:19:44 -0400 Date: Sun, 18 Sep 2005 19:19:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [RFA] print arrays with indexes Message-ID: <20050918191943.GA27191@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Joel Brobecker , gdb-patches@sources.redhat.com References: <20050907053951.GC1540@adacore.com> <20050907132316.GA3622@nevyn.them.org> <20050907202402.GF1540@adacore.com> <20050914171319.GD27542@adacore.com> <20050917204930.GB8777@nevyn.them.org> <20050917215138.GB2496@adacore.com> <20050918034639.GB6990@nevyn.them.org> <20050918054109.GD2496@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00164.txt.bz2 On Sun, Sep 18, 2005 at 10:08:13PM +0300, Eli Zaretskii wrote: > > Date: Sat, 17 Sep 2005 22:41:09 -0700 > > From: Joel Brobecker > > > > > My first reaction was that it would be confusing. We'd have a variable > > > to hold the threshold, and it would always show up in "show" or "help" > > > output, but most of the time its value would be ignored. The trickier > > > something is to document accurately, the more likely it is to confuse > > > users. > > > > I also do not have a strong opinion, but I admit that having one > > knob seems a bit simpler to me (in terms of the user interface). > > Okay, but I still am missing something: we already have a couple of > "set SOMETHING" commands that use the convention that setting a limit > to zero (or -1 in one case) means unlimited. Can't we use this in the > case in point, rather than inventing a new add_* interface? Given Yes, we do have a lot of such interfaces. The problem is that this one has two special values, not just one: always on, always off, and off if the number of elements is above a certain limit. We could do "0 is on, N is threshold, UINT_MAX is off", but in that case, I'd rather give 0 and UINT_MAX names of "on" and "off" so that "show" output is more intelligible. We already do this for var_uinteger and var_integer, which show up as "unlimited". > that we already have so many different add_command interfaces (and > all but 2 of them are undocumented), I'd rather not introduce yet > another interface unless we really have to. Well, then, perhaps this would be a good time for us to document them? :-) If Joel doesn't have time, I'll do it. -- Daniel Jacobowitz CodeSourcery, LLC