> In <200002012348.XAA28479@black-star.demon.co.uk>
> mpumford@black-star.demon.co.uk wrote:
> 
> > > resettod: 32/01/2000 13:35:14
> > > 
> > > Are there something wrong in arm32/dev/todclock.c:resettodr() ?
> 
> > I'd say so. My Risc PC produced the same message. A quick glance at the code 
> > didn't reveal any obvious problems. Are you going to send-pr this or should I?
> 
> Does the attached patch fix this?
> (My CATS is working as NFS server so I cannot test right now...)
> ---
> Izumi Tsutsui
> tsutsui@ceres.dti.ne.jp
> 
> --- todclock.c.orig	Sun Feb 13 23:37:47 2000
> +++ todclock.c	Sun Feb 13 23:39:22 2000
> @@ -222,7 +222,7 @@
>  		month[1]=29;
>  	else
>  		month[1]=28;
> -	while ((sec/SECPERDAY) > month[mon]) {
> +	while ((sec / SECPERDAY + 1) > month[mon]) {
>  		sec -= month[mon]*SECPERDAY;
>  		mon++;
>  	}


Why not:

--- todclock.c.orig	Sun Feb 13 23:37:47 2000
+++ todclock.c	Sun Feb 13 23:39:22 2000
@@ -222,7 +222,7 @@
 		month[1]=29;
 	else
 		month[1]=28;
-	while ((sec/SECPERDAY) > month[mon]) {
+	while (sec >= month[mon]*SECPERDAY) {
 		sec -= month[mon]*SECPERDAY;
 		mon++;
 	}


Since (in a rough order of importance)
1) It's more obvious what is going on
2) Multiplication is faster on most machines than division, and especially 
so on the ARM
3) You've then got a CSE that the compiler can extract