Replace rev 1.33 with a real fix. The problem was integer overflows

when trying to store the year in a signed int.  The maximum time_t on ia64
is around 292 billion years in the future, but 'int' and struct tm.tm_year
can only represent then ext 2.1 billion years or so.

This solves the problem of mktime/localtime looping on ia64.  Unfortunately,
the standards say that tm_year is an 'int', so we are still stuck with a
y2147483647 bug.  bash2's configure script looks for bugs in mktime() and
fails on ia64 because of this.  However, mktime() on FreeBSD fails the test
normally anyway so this is no big loss.

This change does not affect any other platforms besides ia64.

Approved by:	re
This commit is contained in:
Peter Wemm 2002-12-02 01:05:08 +00:00
parent 431dda01b6
commit a5bf4e71ef

View File

@ -1222,7 +1222,7 @@ struct tm * const tmp;
const struct lsinfo * lp;
long days;
long rem;
int y;
long y;
int yleap;
const int * ip;
long corr;
@ -1291,7 +1291,7 @@ struct tm * const tmp;
y = EPOCH_YEAR;
#define LEAPS_THRU_END_OF(y) ((y) / 4 - (y) / 100 + (y) / 400)
while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) {
int newy;
long newy;
newy = y + days / DAYSPERNYEAR;
if (days < 0)
@ -1475,12 +1475,6 @@ int * const okayp;
** (this works whether time_t is signed or unsigned).
*/
bits = TYPE_BIT(time_t) - 1;
/*
* Limit to 32 bits or the things go crazy
* when it tries to figure out times near 2^62 etc.
*/
if (bits > 31)
bits = 31;
/*
** If time_t is signed, then 0 is just above the median,
** assuming two's complement arithmetic.