From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21066 invoked by alias); 20 Sep 2005 19:31:44 -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 21037 invoked by uid 22791); 20 Sep 2005 19:31:35 -0000 Received: from s142-179-108-108.bc.hsia.telus.net (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 20 Sep 2005 19:31:35 +0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id C787A47E75; Tue, 20 Sep 2005 12:31:32 -0700 (PDT) Date: Tue, 20 Sep 2005 19:31:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] print arrays with indexes Message-ID: <20050920193132.GY2496@adacore.com> References: <20050917204930.GB8777@nevyn.them.org> <20050917215138.GB2496@adacore.com> <20050918034639.GB6990@nevyn.them.org> <20050918054109.GD2496@adacore.com> <20050918191943.GA27191@nevyn.them.org> <20050920073058.GR2496@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2005-09/txt/msg00178.txt.bz2 > > 1. If array size > threshold, then print indexes > > 2. If array size < threshold, then print indexes > > The second, I think: it makes sense to ask for arrays that are not too > large to be printed with additional info. This is fine with me. > > Now, the sticky part: How to implement this new interface. > > > > I'll argue that it's best to implement something new. I don't like > > hijacking an old interface to unsigned integer and adding some aliases > > to a couple of values. My reasoning is that saying that OFF is an alias > > for UINT_MAX will make sense for certain cases while it actually won't > > for other cases. Actually, which value to use for OFF will depend on > > the what the threashold actually means. > > If you accept my view above, then threshold value of zero means > unlimited. We already have several set/show commands that behave this > way, so I don't see any problem with having yet another. Well, looks like you are now suggesting that we drop the idea of having on/off aliases, to which I disagree. How about people like me who want this feature OFF all the time, except in rare occasions? > > I vote for a new API. > > I don't see any reason for a new API. If you accept my view on the necessity of having on/off values instead of just controlling this feature with a plain integer, then maybe we have a more compelling reason? > > I think we should also review the usage of the current ones, probably > > cleanup a bit some of the ones that were on the road to obsolescence > > (IIRC), maybe rationalize a bit more our API if needed, and add some > > documentation. But that should be a separate thread. I don't think I > > will be able to handle all of this, but I can certainly help. > > That sounds like a lot of unnecessary work for such an obscure > feature, IMHO. To me, it's totally unrelated to what we are discussing. It's just a idea that popped up during the course of this discussion. You said that our current API for set/show commands is poorly documented. Daniel and I offer to look into the documentation problem, and I also suggest that this is a good time to do any cleanup if needed. -- Joel