From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NRrqq-0001NH-Fr for qemu-devel@nongnu.org; Mon, 04 Jan 2010 13:40:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NRrql-0001Dq-NI for qemu-devel@nongnu.org; Mon, 04 Jan 2010 13:40:23 -0500 Received: from [199.232.76.173] (port=55808 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NRrql-0001DH-BB for qemu-devel@nongnu.org; Mon, 04 Jan 2010 13:40:19 -0500 Received: from mx20.gnu.org ([199.232.41.8]:53271) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NRrqh-0000WR-KS for qemu-devel@nongnu.org; Mon, 04 Jan 2010 13:40:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NRrqa-0000Ew-AA for qemu-devel@nongnu.org; Mon, 04 Jan 2010 13:40:09 -0500 Message-ID: <4B4235F9.4070709@redhat.com> Date: Mon, 04 Jan 2010 19:39:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 03/19] avoid dubiously clever code in win32_start_timer References: <1261382970-23251-1-git-send-email-pbonzini@redhat.com> <1261382970-23251-4-git-send-email-pbonzini@redhat.com> <4B4242A8.2020305@codemonkey.ws> In-Reply-To: <4B4242A8.2020305@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 01/04/2010 08:34 PM, Anthony Liguori wrote: > On 12/21/2009 02:09 AM, Paolo Bonzini wrote: >> The code is initializing an unsigned int to UINT_MAX using "-1", so that >> the following always-true comparison seems to be always-false at a >> first look. Just remove the if. > > This really needs a better comment message as at first it wasn't obvious > to me that this was correct. > > start_timer is only ever called once and as such, the check here is > unnecessary. It's not incorrect, it's just more robust than it needs to be. > > I'm not sure it's really worth removing to be honest. I didn't like the comparison with -1 being always true. I'll update with a comment. Paolo