From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28757 invoked by alias); 16 Sep 2004 00:29:10 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28732 invoked from network); 16 Sep 2004 00:29:05 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 16 Sep 2004 00:29:05 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 7F1C547D92; Wed, 15 Sep 2004 17:29:04 -0700 (PDT) Date: Thu, 16 Sep 2004 00:29:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: better name for var_integer et.al. Message-ID: <20040916002904.GZ5843@gnat.com> References: <414883EC.9000500@gnu.org> <20040915181900.GW5843@gnat.com> <4148A713.3000704@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4148A713.3000704@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00137.txt.bz2 > >Ada calls such numbers "Positive". var_positive might be a good name. > > Or var_ordinal_number (vs cardinal number)? Yew! (sorry). I prefer var_positive. Or var_nonzero_positive. > >>> /* Like var_uinteger but signed. *VAR is an int. The user can type 0 > >>> to mean "unlimited", which is stored in *VAR as INT_MAX. */ > >>> var_integer, > > Well, the "set backtrace limit 100" bug comes from a comparison between > signed (frame->limit == -1) vs unsigned (backtrace_limit == 100) > comparison which is from a var_uinteger. > > Using var_integer "fixes" it but lets a user enter -100. What would it mean, at the semantic level if the user entered such a value? Shouldn't this value always be positive, with a zero value being infinity? Anyway, if we need to keep this kind of variables, how about var_nonzero_integer (in line with one of the proposals above). > >>> /* ZeroableInteger. *VAR is an int. Like Unsigned Integer except > >>> that zero really means zero. */ > >>> var_zinteger, > > > > > >var_integer? (assuming we get rid of the non-zero signed integer) And then this one could become var_integer (an integer range contains value zero by default, so no need to emphasize it with the 'z', IMHO). -- Joel