From nobody@FreeBSD.ORG Thu Apr 29 22:13:47 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id CE1E5152D7; Thu, 29 Apr 1999 22:13:47 -0700 (PDT)
Message-Id: <19990430051347.CE1E5152D7@hub.freebsd.org>
Date: Thu, 29 Apr 1999 22:13:47 -0700 (PDT)
From: jobaldwi@vt.edu
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: Calendar doesn't always handle 'last' days right...
X-Send-Pr-Version: www-1.0

>Number:         11399
>Category:       bin
>Synopsis:       Calendar doesn't always handle 'last' days right...
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 29 22:20:01 PDT 1999
>Closed-Date:    Sat Jun 16 08:24:14 PDT 2001
>Last-Modified:  Sat Jun 16 08:24:53 PDT 2001
>Originator:     John Baldwin
>Release:        3.1-STABLE
>Organization:
>Environment:
FreeBSD john.baldwin.cx 3.1-STABLE FreeBSD 3.1-STABLE #15: Mon Apr 19 22:48:08 EDT 1999     root@john.baldwin.cx:/usr/source/src/sys/compile/JOHN  i386
>Description:
For days that are specified as the last weekday of the month, calendar
can sometimes choke and extend the length of a month and have the specified
event mentioned one week late.  See the example below for this to make sense.
>How-To-Repeat:
> calendar -f /usr/share/calendar/calendar.holiday -t 30.4
Apr 33* Arbor Day in Wyoming (last Monday)
Apr 33* Confederate Memorial Day in Alabama & Mississippi (last Monday)

April dosen't have 33 days, and the days above should be 26, not 33.
Note that this only fails on April 30, it works for every other day.

>Fix:
Here's an ugly hack that ignores days whose dates are greater than the
number of days in the month for these types of day specifications, but
someone who understands all of the math and whatnot should figure out
why it is generating 33 instead of 26 for the day.

RCS file: /usr/cvs/src/usr.bin/calendar/day.c,v
retrieving revision 1.11
diff -u -r1.11 day.c
--- day.c       1997/10/26 12:51:30     1.11
+++ day.c       1999/04/30 05:13:06
@@ -325,8 +325,9 @@
                    v2 = tp->tm_mday + (((day - 1) - tp->tm_wday + 7) % 7);
 
                    /* (month length - day) / 7 + 1 */
-                   if (((int)((cumdays[month+1] - 
-                              cumdays[month] - v2) / 7) + 1) == -v1)
+                   if ((((int)((cumdays[month+1] - 
+                              cumdays[month] - v2) / 7) + 1) == -v1) &&
+                       (v2 <= cumdays[month+1] - cumdays[month]))
                        /* bingo ! */
                        day = v2;
                    


>Release-Note:
>Audit-Trail:

From: Alex Vasylenko <lxv@nest.org>
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:
 <a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=10868">bin/10868</a>
 <a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=15182">bin/15182</a>
 
 --Alex.
 
State-Changed-From-To: open->closed 
State-Changed-By: mikeh 
State-Changed-When: Sat Jun 16 08:24:14 PDT 2001 
State-Changed-Why:  
Fixed in rev 1.12 of day.c. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=11399 
>Unformatted:
