From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19076 invoked by alias); 1 Feb 2006 21:17:15 -0000 Received: (qmail 19065 invoked by uid 22791); 1 Feb 2006 21:17:14 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 01 Feb 2006 21:17:12 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F4PLe-0003fS-3Q; Wed, 01 Feb 2006 16:17:06 -0500 Date: Wed, 01 Feb 2006 21:17:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [RFC] Clean up var_integer/var_uinteger/var_zinteger mess Message-ID: <20060201211706.GA13981@nevyn.them.org> Mail-Followup-To: Jim Blandy , Mark Kettenis , gdb-patches@sourceware.org References: <200601311131.k0VBVjf8022306@jop31.nfra.nl> <8f2776cb0601312153s72d75a48ha6bc2fe75050d4fc@mail.gmail.com> <200602011612.k11GCTK1017502@elgar.sibelius.xs4all.nl> <8f2776cb0602011049u2479c5e5n7dec732b59927573@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0602011049u2479c5e5n7dec732b59927573@mail.gmail.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00009.txt.bz2 On Wed, Feb 01, 2006 at 10:49:22AM -0800, Jim Blandy wrote: > On 2/1/06, Mark Kettenis wrote: > > Actually, it'd make sense if the existing > > var_integer/var_uinteger/var_zinteger would accept "unlimited". > > That'd make your var_limit unnecessary. > > > > Does anyone see any problems with that? > > Well, I presume that sometimes (often) those are used for limits of > something, and sometimes they're genuine integers. Surely there's > something in GDB where a negative value would make sense. I don't > like the idea of accepting "unlimited" for a quantity that isn't a > limit on anything. > > Then, of course, there's aix-thread.c which is using zinteger for a boolean. There's lots of (mis- ?) uses of all the var_ types all over GDB. I think that (A) we ought to clean them all up, and (B) it's going to require checking them all to do it. Definitely some of the current uses don't make sense - for instance: (gdb) show remote hardware-breakpoint-limit The maximum number of target hardware breakpoints is 4294967295. A bunch of others ought to be booleans. A bunch of others are actual integer values - sometimes signed would make sense, sometimes it wouldn't, e.g. ser-go32.c. I'd like to be able to set the ones that are limits to "unlimited". Caveats are preserving the existing "set to zero" behavior where it makes sense to do so, updating the manual, and not being able to set non-limits to unlimited. -- Daniel Jacobowitz CodeSourcery