[comp.sources.d] Wanted: opinions on the correctness of a fix

ado@elsie.UUCP (Arthur David Olson) (05/31/88)

A while back, there was a report of a problem with the file-based time
conversion software when used on 3B1s.  The attached change to "localtime.c"
may be the fix; then again, it may not be.  In particular, I'm not sure that
conditioning on "m68k" is the right thing to do.  If any readers can either
bless or curse the fix, I'd appreciate it.
-- 
		Market swaps ends for Chinese native.  (5)
	ado@ncifcrf.gov			ADO is a trademark of Ampex.

*** 4.1/localtime.c	Mon May 30 12:49:30 1988
--- 4.6/localtime.c	Mon May 30 12:49:47 1988
***************
*** 1,6 ****
  #ifndef lint
  #ifndef NOID
! static char	elsieid[] = "@(#)localtime.c	4.1";
  #endif /* !defined NOID */
  #endif /* !defined lint */
  
--- 1,6 ----
  #ifndef lint
  #ifndef NOID
! static char	elsieid[] = "@(#)localtime.c	4.6";
  #endif /* !defined NOID */
  #endif /* !defined lint */
  
***************
*** 389,394 ****
--- 389,403 ----
  	}
  	days = *clock / SECSPERDAY;
  	rem = *clock % SECSPERDAY;
+ #ifdef mc68k
+ 	if (*clock == 0x80000000) {
+ 		/*
+ 		** A 3B1 muffs the division on the most negative number.
+ 		*/
+ 		days = -24855;
+ 		rem = -11648;
+ 	}
+ #endif /* mc68k */
  	rem += (offset - corr);
  	while (rem < 0) {
  		rem += SECSPERDAY;