From owner-cvs-all@FreeBSD.ORG Sun Jun 1 06:53:16 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D72537B401; Sun, 1 Jun 2003 06:53:16 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03F843FF5; Sun, 1 Jun 2003 06:48:14 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id XAA27175; Sun, 1 Jun 2003 23:48:04 +1000 Date: Sun, 1 Jun 2003 23:48:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Erik Trulsson In-Reply-To: <20030531203751.GA38298@falcon.midgard.homeip.net> Message-ID: <20030601231715.W11782@gamplex.bde.org> References: <200305312023.h4VKNkKq037126@repoman.freebsd.org> <20030531203751.GA38298@falcon.midgard.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Poul-Henning Kamp cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/isa clock.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2003 13:53:17 -0000 On Sat, 31 May 2003, Erik Trulsson wrote: > On Sat, May 31, 2003 at 01:23:46PM -0700, Poul-Henning Kamp wrote: > > phk 2003/05/31 13:23:46 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/isa clock.c > > Log: > > Don't rely on boolean expression evaluating to 1 or 0 by default. > > Why not? In C the relational operators (including '==') *always* > evaluate to 1 or 0. One can rely on that. > I.e. this change doesn't really accomplish anything except make the > expression somewhat more complicated. The result of the expression is used as a non-boolean in some places, and setting its values explicitly is clearer there. The values are 0 and the number of extra days in February in a leap year; the latter just happens to be 1. In places where the expression is used as a boolean, the change is an obfuscation. %%% $ grep LEAPYEAR clock.c #define LEAPYEAR(y) (((u_int)(y) % 4 == 0) ? 1 : 0) if ((month > 2) && LEAPYEAR(year)) days += DAYSPERYEAR + LEAPYEAR(y); for (y = 1970, m = DAYSPERYEAR + LEAPYEAR(y); y++, m = DAYSPERYEAR + LEAPYEAR(y)) if (m == 1 && LEAPYEAR(y)) %%% The correct fix here was to replace LEAPYEAR(y) by (LEAPYEAR(y) ? 1 : 0) in the 3 expressions that add it, and not change the boolean expression LEAPYEAR(y). LEAPYEAR() is correctly named for a boolean expression that classifies leap years but bogusly named for the non-boolean adjustment to the number of days in February, so it shouldn't have been changed to give the latter as its primary result and the former as an alias. Bruce