From owner-freebsd-bugs Mon Apr 3 3:40: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id C6B8A37BA82 for ; Mon, 3 Apr 2000 03:40:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA99439; Mon, 3 Apr 2000 03:40:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 3 Apr 2000 03:40:03 -0700 (PDT) Message-Id: <200004031040.DAA99439@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Alex Vasylenko Subject: Re: bin/11399: Calendar doesn't always handle 'last' days right... Reply-To: Alex Vasylenko Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/11399; it has been noted by GNATS. From: Alex Vasylenko To: freebsd-gnats-submit@FreeBSD.org, jobaldwi@vt.edu Cc: Subject: Re: bin/11399: Calendar doesn't always handle 'last' days right... Date: Mon, 3 Apr 2000 03:30:42 -0700 John, I think that the fix you recommend is the right fix to do. Here's why: day.c:325 v2 = tp->tm_mday + (((day - 1) - tp->tm_wday + 7) % 7); day here is the requested day of week (Sun == 1, Mon == 2, etc.) the meaning of v2 would be something like: "the day of month when the day of the week == requested day of the week", obviously if v2 is greater than cumdays[month+1]-cumdays[month], which is a month length, there's no such days left. later at: day.c: 328 if (((int)((cumdays[month+1] - 329 cumdays[month] - v2) / 7) + 1) == -v1) the code assumes that v2 is a legitimate day of month. additional condition, that you suggest fixes the problem. the same fix also applies to: bin/10868 bin/15182 --Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message