From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15522 invoked by alias); 5 Mar 2013 18:07:01 -0000 Received: (qmail 15375 invoked by uid 22791); 5 Mar 2013 18:06:59 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Mar 2013 18:06:23 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r25I6K3m010083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 13:06:20 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r25I6I1R023813; Tue, 5 Mar 2013 13:06:19 -0500 Message-ID: <5136341A.4050605@redhat.com> Date: Tue, 05 Mar 2013 18:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Doug Evans CC: Yao Qi , gdb-patches Subject: Re: [PATCH 1/2] use zuinteger_unlimited for some remote commands References: <1360934868-5807-1-git-send-email-yao@codesourcery.com> <1360934868-5807-2-git-send-email-yao@codesourcery.com> <51349F6E.8020101@redhat.com> <5134B192.8080507@codesourcery.com> <5134C9DD.2070205@redhat.com> <5135A26A.6030608@codesourcery.com> <5135EC1D.9030601@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-03/txt/msg00157.txt.bz2 On 03/05/2013 05:33 PM, Doug Evans wrote: > On Tue, Mar 5, 2013 at 4:59 AM, Pedro Alves wrote: >> We could just as >> well treat the variable internally as the correct type of >> unsigned int, and handle UINT_MAX as unlimited internally too. > > Part of me is weeping that we didn't take this route. In a way, I suppose I don't like it, because it ties a magic _positive_ number as upper bound in the user/api interface. And that also invites problems and tears down the road. :-) IOW, the magic number UINT_MAX actually depends on host int width (32/64-bit, etc., exotic, but they exist), so e.g., in theory python scripts may have trouble with that. Also, if at some point we want to extend the range of these variables to 64-bit, the magic number has to change, as then UINT_MAX is midway through the valid range... Signed negative "-1", "-2", etc. don't have that issue. They mean the same whatever the width. (And if we want another magic number in addition to "unlimited"? Say, we need "disabled", while "0" still meaning "0". Reserving and writting "UINT_MAX-1" gets much uglier then... Maybe we'll end up with a struct instead of packing things into a single number.) That's a load of theory though. We could also just declare the command is bound to a uint32_t variable, and document it as such. But still, OTOH, this same reasoning percolates all the way to the remote protocol -- numbers in the remote protocol don't actually have an upper bound / width hard coded. So there's a possible compatibility issue here. Once UINT_MAX for one target is deemed "not big enough", should we add new, different packets? Or should GDB be adjusted to cope internally, while the visible interfaces (cli/python/RSP) remain the same, only that they support larger values? The other approach (signed, -1) avoids actually thinking too much about all these issues, and pondering on their significance, hence my preference. :-) > If uinteger is in the name, anything else just invites problems, if > not tears ... :-) To me, it indicates that for "normal" values, this command only really accepts positive values. Negatives are almost an implementation detail. We could make it fully an implementation detail, if "set foo unlimited" was supported (I do think it should), and, if that isn't actually problematic for frontends/python (is it?), though I could imagine the negative values being more convenient in scripts than having to check for special non-numbers. With all that said -- it's fine with me if people remove the u. -- Pedro Alves