d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

struct tm.tm_year is listed as 'years since 1900', and is signed. On

Browse Source 
64 bit systems, years roughly -2^31 through 2^31 can be represented in
time_t without any trouble.  32 bit time_t systems only range from
roughly 1902 through 2038.  As a consequence, none of the date munging
code for all the various calendar tweaks before then is present.  There
are other problems including the fact that there was no 'year zero' and
so on.  So rather than get excited about trying to figure out when the
calendar jumped by two weeks etc, simply disallow negative (ie: prior to
1900) years.

This happens to have an important side effect.  If you bzero a 'struct
tm', it corresponds to 'Jan 0, 1900, 00:00 GMT'.  This happens to be
representable (after canonification) in 64 bit time_t space.  Zero tm
structs are generally an error and mktime normally returns -1 for them.
Interestingly, it tries to canonify the 'jan 0' to 'dec 31, 1899', ie:
year -1.  This conveniently trips the negative year test above, which
means we can trivially detect the null 'tm' struct.

This actually tripped up code at work. :-/  (Don't ask)
This commit is contained in:
peter 2004-08-24 00:15:37 +00:00
parent 5c1c6f2674
commit f0aa809d44
1 changed files with 3 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
lib/libc/stdtime/localtime.c
View File

@ -1487,6 +1487,9 @@ const int do_norm_secs;
} }
if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE))
return WRONG; 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) if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN)
saved_seconds = 0; saved_seconds = 0;
else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) {