From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10489 invoked by alias); 1 Feb 2006 19:24:31 -0000 Received: (qmail 10480 invoked by uid 22791); 1 Feb 2006 19:24:31 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Feb 2006 19:24:29 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k11JNoCv024612; Wed, 1 Feb 2006 20:23:50 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k11JNoxn030836; Wed, 1 Feb 2006 20:23:50 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k11JNn7Q024255; Wed, 1 Feb 2006 20:23:49 +0100 (CET) Date: Wed, 01 Feb 2006 19:24:00 -0000 Message-Id: <200602011923.k11JNn7Q024255@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: jimb@red-bean.com CC: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org In-reply-to: <8f2776cb0602011049u2479c5e5n7dec732b59927573@mail.gmail.com> (message from Jim Blandy on Wed, 1 Feb 2006 10:49:22 -0800) Subject: Re: [RFC] Clean up var_integer/var_uinteger/var_zinteger mess References: <200601311131.k0VBVjf8022306@jop31.nfra.nl> <8f2776cb0601312153s72d75a48ha6bc2fe75050d4fc@mail.gmail.com> <200602011612.k11GCTK1017502@elgar.sibelius.xs4all.nl> <8f2776cb0602011049u2479c5e5n7dec732b59927573@mail.gmail.com> 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/msg00007.txt.bz2 > X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on > elgar.sibelius.xs4all.nl > X-Spam-Level: > X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no > version=3.1.0 > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; > s=beta; d=gmail.com; > h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; > b=TFTIQB+EK02V1vfXwI4QJr/gwBrh3UD5JTREmxEUO/A7bevYVtY02UcXlTjdbxMdWVK0UFIL+7lGFhq9OI4I4ZDiTkjxogv8dHMT4YB0XjPaJwFosrXjv5aSAOTv7blG57qzR2FfqT+q/8wjS018LVkizr+i29iXHZipUDHhXDc= > Date: Wed, 1 Feb 2006 10:49:22 -0800 > From: Jim Blandy > Sender: jimblandy@gmail.com > Cc: gdb-patches@sourceware.org > Content-Disposition: inline > X-XS4ALL-DNSBL-Checked: mxdrop24.xs4all.nl checked 64.233.162.193 against DNS blacklists > X-Virus-Scanned: by XS4ALL Virus Scanner > X-XS4ALL-Spam-Score: 0 () > X-XS4ALL-Spam: NO > Envelope-To: mark.kettenis@xs4all.nl > X-MIME-Autoconverted: from quoted-printable to 8bit by mxdrop24.xs4all.nl id k11InHwe077021 > X-UIDL: 1138819766._smtp.mxdrop24.77065,S=2619 > > 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. Well, the current code already prints "unlimited" for var_integer/var_uinteger. I'd say it is only logical that they can be set to "unlimited" too. Guess your var_zinteger is your "genuine" integer; we probably shouldn't accept "unlimited" for those. > Then, of course, there's aix-thread.c which is using zinteger for a boolean. Of course. That's the proper type for boolean expressions ;-). Mark