PERFORCE change 60029 for review

[Peter Wemm]

http://perforce.freebsd.org/chv.cgi?CH=60029

Change 60029 by peter at peter_daintree on 2004/08/19 02:04:36

	For a 32 bit time_t machine, the representable years range from
	approx 1902 through 2038.  Nothing has to worry about negative
	tm_year values.  Lots of funny things happened to the calendar
	over the preceding few centuries that are not covered in the
	time system here.  However, 64 bit time_t systems can represent
	tm_year for the next few billion years without an overflow. And
	it is signed, so theoretically it can represent 1900+year for the
	last few billion years.  But, we dont have the calendar munging
	so this is of little value.  So, clamp the tm_year values as
	>= 0, both for POLA and as a convenient safety test.  A totally
	null 'struct tm' is 'jan 0, 1900, 00:00:00'.  But there isn't a 0th
	day in the month, so it is normalized to 'dec 31, 1899, 00:00:00'.
	Adding the < 0 test means we catch this input value which is fairly
	likely to have been bogus from the start.

Affected files ...

.. //depot/projects/hammer/lib/libc/stdtime/localtime.c#6 edit

Differences ...

==== //depot/projects/hammer/lib/libc/stdtime/localtime.c#6 (text+ko) ====

@@ -1487,6 +1487,9 @@
 	}
 	if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE))
 		return WRONG;
+	/* Don't go below 1900 for POLA */
+	if (yourtm.tm_year < 0)
+		return WRONG;
 	if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN)
 		saved_seconds = 0;
 	else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) {