From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20669 invoked by alias); 24 Aug 2012 17:06:14 -0000 Received: (qmail 20652 invoked by uid 22791); 24 Aug 2012 17:06:12 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-gg0-f201.google.com (HELO mail-gg0-f201.google.com) (209.85.161.201) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Aug 2012 17:05:58 +0000 Received: by ggnq2 with SMTP id q2so291805ggn.0 for ; Fri, 24 Aug 2012 10:05:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:content-type:content-transfer-encoding:message-id:date :to:cc:subject:in-reply-to:references:x-mailer:from :x-gm-message-state; bh=4a09bl7AzBykhisDnEvVJdlPki4L1TG6BY5FtP1aX2g=; b=ZaFfWCX4Cq/GYslo4Bku2UasoU5v3w5iR0JqOuCNvkkmEiFdQkjiCBsaeDxEyfipYs 7ItfuiZ9RMErj/MylcGOMU60flfQ/wxMkWgpVb8Om90bzj9JE95SwmOiXw7RGsnTSi9r j8GVTn6TgUXosvQLPL6YxxjTDYaD2Ar7ynEmY0r4U2k2osf8SiriMDQXA5yhQctpWZUJ mDlrdakMHP/Gnxg6rpUoLhw9J6M9dAdrLY9prmAcOe9ZMb4O/yqJCc38UnuMhoSwSnu+ +r43EdnFvg7o70S7kwRIxaab9dySEYU+wnKdmLDp+gpJi0pjFpNtzU5QHnbbZlIX+Tmk SPUA== Received: by 10.236.193.40 with SMTP id j28mr2872945yhn.21.1345827957720; Fri, 24 Aug 2012 10:05:57 -0700 (PDT) Received: by 10.236.193.40 with SMTP id j28mr2872940yhn.21.1345827957666; Fri, 24 Aug 2012 10:05:57 -0700 (PDT) Received: from wpzn3.hot.corp.google.com (216-239-44-65.google.com [216.239.44.65]) by gmr-mx.google.com with ESMTPS id c61si3021416yhm.3.2012.08.24.10.05.57 (version=TLSv1/SSLv3 cipher=AES128-SHA); Fri, 24 Aug 2012 10:05:57 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com (ruffy2.mtv.corp.google.com [172.18.110.129]) by wpzn3.hot.corp.google.com (Postfix) with ESMTP id 3084A100047; Fri, 24 Aug 2012 10:05:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20535.46196.619465.922388@ruffy2.mtv.corp.google.com> Date: Fri, 24 Aug 2012 17:06:00 -0000 To: Yao Qi Cc: Subject: Re: [PATCH 1/3] var_integer -> var_uinteger In-Reply-To: <50372591.7080404@codesourcery.com> References: <7A6A55B4-0293-4AD6-AB1F-B3169F8ADCC1@cs.umd.edu> <1344871663-915-1-git-send-email-yao@codesourcery.com> <1344871663-915-2-git-send-email-yao@codesourcery.com> <20534.29766.629459.204573@ruffy2.mtv.corp.google.com> <50372591.7080404@codesourcery.com> From: dje@google.com X-Gm-Message-State: ALoCoQnGvs8tdqNOYwn0wELCP+RP9o+thn/p3fu8sj48kXQK4mpF4CXNzYOluZzrXUzoBbYiSVWJkqdSU9w7veHcxtwSfcnLlz9YcXL4gItiABbBOfWa5/TEEgLrW7ycP6nXwamNoT1ixNY1QjgGcmkZv8W9ypCw004C52/v9iBMe5Q1Rsnh+zmFeTpEmjZZnLxK6olCf/oBRw+OM2Jf22ex4McF9NMuCA== X-IsSubscribed: yes 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: 2012-08/txt/msg00750.txt.bz2 Yao Qi writes: > On 08/24/2012 02:19 AM, dje@google.com wrote: > > > - if (history_size == INT_MAX) > > > + if (history_size == UINT_MAX) > > > unstifle_history (); > > > - else if (history_size >= 0) > > > - stifle_history (history_size); > > > + else if (history_size >= INT_MAX) > > > + /* The type of parameter in stifle_history is int, so check the range. */ > > > + error (_("History size must be less than %d"), INT_MAX); > > > > I think we don't want to remove resetting "history_size = INT_MAX;" > > in the error case here (but see below). > > Checking the value is negative should be done in do_set_command, and > patch was posted here, > > [PATCH 1/3] var_zuinteger_unlimited and 'set listsize'. > http://sourceware.org/ml/gdb-patches/2012-08/msg00021.html > > Posting a new one has been on my TODO list, and I'll do it once this > patch goes in. Ah. My point was that if the user sets the value to INT_MAX+1, for example, and you flag that as an error, then the value should be reset back to something legal. But no matter, if we go with all values being legal. :-) > @@ -1445,15 +1445,12 @@ show_commands (char *args, int from_tty) > static void > set_history_size_command (char *args, int from_tty, struct cmd_list_element *c) > { > - if (history_size == INT_MAX) > + /* The type of parameter in stifle_history is int, so value from INT_MAX and > + up means "unlimited". */ > + if (history_size >= INT_MAX) > unstifle_history (); > - else if (history_size >= 0) > - stifle_history (history_size); > else > - { > - history_size = INT_MAX; > - error (_("History size must be non-negative")); > - } > + stifle_history (history_size); > } One issue that arises is if the user sets the value to, say, INT_MAX+1 we call unstifle_history, but show "show hist size" will print INT_MAX+1 instead of "unlimited". If we go this route, perhaps any value >= INT_MAX should cause the underlying value to be set to UINT_MAX so that "show" will print "unlimited".