From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14659 invoked by alias); 4 Mar 2013 16:21:01 -0000 Received: (qmail 14593 invoked by uid 22791); 4 Mar 2013 16:20: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; Mon, 04 Mar 2013 16:20:50 +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 r24GKlNT009437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Mar 2013 11:20:47 -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 r24GKjF2022832; Mon, 4 Mar 2013 11:20:46 -0500 Message-ID: <5134C9DD.2070205@redhat.com> Date: Mon, 04 Mar 2013 16:21: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: Yao Qi CC: gdb-patches@sourceware.org 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> In-Reply-To: <5134B192.8080507@codesourcery.com> Content-Type: text/plain; charset=UTF-8 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/msg00091.txt.bz2 On 03/04/2013 02:37 PM, Yao Qi wrote: > On 03/04/2013 09:19 PM, Pedro Alves wrote: >> On 02/15/2013 01:27 PM, Yao Qi wrote: >>> -int remote_hw_watchpoint_limit = -1; >>> -int remote_hw_watchpoint_length_limit = -1; >>> -int remote_hw_breakpoint_limit = -1; >>> +static unsigned int remote_hw_watchpoint_limit = UINT_MAX; >>> +static unsigned int remote_hw_watchpoint_length_limit = UINT_MAX; >>> +static unsigned int remote_hw_breakpoint_limit = UINT_MAX; >> >> ... >> >>> @@ -8259,7 +8255,7 @@ remote_check_watch_resources (int type, int cnt, int ot) >>> { >>> if (remote_hw_watchpoint_limit == 0) >>> return 0; >>> - else if (remote_hw_watchpoint_limit < 0) >>> + else if (remote_hw_watchpoint_limit == UINT_MAX) >> >> This made me notice something with var_zuinteger_unlimited. >> >> What's the point of making it work with unsigned variables, >> and UINT_MAX, if the contents of the variable are actually >> treated as int everywhere in cli-setshow.c? (and val is >> still cut at INT_MAX). Vis, e.g., >> > (swapping for better answer:) > That is reason I change type of "remote_hw_watchpoint_limit" from signed to > unsigned. Their default value is unlimited (-1), so I initialize them to UINT_MAX. > Originally I used "(unsigned int) -1", but UINT_MAX is better as "unlimited" here. That's all clear, and a _consequence_ of var_zuinteger_unlimited wanting an unsigned variable. > Yes, in cli-setshow.c, the val is treated as signed integer, because -1 stands for unlimited. > Outside of cli, var_zuinteger_unlimited is about a unsigned integer with a unlimited > state. But then, var_zuinteger_unlimited treats numbers from INT_MAX to UINT_MAX-1 as invalid, and, while forbidding any other negative number except -1 at the same time. (gdb) set listsize 2147483647 (INT_MAX) integer 2147483647 out of range (gdb) set listsize 2147483647+1 only -1 is allowed to set as unlimited (gdb) set listsize 4294967295U (UINT_MAX) integer 4294967295 out of range (gdb) set listsize 4294967295U-1 integer 4294967294 out of range Okay, so I notice that's documented in: /* ZeroableUnsignedInteger with unlimited value. *VAR is an unsigned int, but its range is [0, INT_MAX]. -1 stands for unlimited. */ var_zuinteger_unlimited, But I ask, what's either: - the point of making it internally signed with things like: if (*(int *) c->var != val) and forbidding INT_MAX..UINT_MAX-1. (Not that I'm arguing it should). The care to only accept -1 and not any other negative number made me think numbers in that range should be accepted. - the point of making it externally unsigned if it only accepts [0, INT_MAX]. If the variable assigned to the command was signed too, then this range would be both implicit and explicit, meaning, one weird detail less the user of the API needs to know. BTW, if the variable is unsigned, then I believe accessing it as signed as cli-setshow.c does is actually undefined behavior. -- Pedro Alves