From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ9K0-000190-Tw for qemu-devel@nongnu.org; Tue, 12 Jan 2016 19:29:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJ9K0-0006dq-50 for qemu-devel@nongnu.org; Tue, 12 Jan 2016 19:29:56 -0500 Date: Wed, 13 Jan 2016 08:29:48 +0800 From: Fam Zheng Message-ID: <20160113002948.GC25517@ad.usersys.redhat.com> References: <1452490959-10387-1-git-send-email-famz@redhat.com> <1452490959-10387-2-git-send-email-famz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] blockdev: Error out on negative throttling option values List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org, Markus Armbruster On Tue, 01/12 16:00, Alberto Garcia wrote: > On Mon 11 Jan 2016 06:42:38 AM CET, Fam Zheng wrote: > > > The implicit casting from unsigned int to double changes negative > > values into large positive numbers, whereas explicitly casting to > > signed integer first will let us catch the invalid value and report > > error correctly: > > > > $ qemu-system-x86_64 -drive file=null-co://,iops=-1 > > qemu-system-x86_64: -drive file=null-co://,iops=-1: bps/iops/maxs > > values must be 0 or greater > > > > > throttle_cfg->buckets[THROTTLE_BPS_TOTAL].avg = > > - qemu_opt_get_number(opts, "throttling.bps-total", 0); > > + (int64_t)qemu_opt_get_number(opts, "throttling.bps-total", 0); > > It seems to me that the problem is that qemu_opt_get_number() returns a > value different from the one specified in the comand-line. > > How do we even tell the difference between a negative number and its > bit-to-bit positive equivalent? We can't. :( > > If we are going to reject very large numbers I would rather check that > the throtting values are within a sane range and throw an error > otherwise. Yes, that is probably more accurate to the user. Fam