[PATCH 2alt/2] work around unreliable gmtime errors on AIX
- From
Jeff King <peff@peff.net>
- Date
- Apr 1, 2014, 07:45 UTC
- Message-ID
- <20140401074559.GA22591@sigill.intra.peff.net>
- In-Reply-To
- <20140401073848.GA22023@sigill.intra.peff.net>
AIX's gmtime will happily overflow the tm_year field. Let's catch this error before handing the value to gmtime.
Signed-off-by: Jeff King <peff@peff.net> --- This is an alternative to loosening the test in t4212.
It's really not _that_ ugly. The "LL" here may not be portable, though. 32-bit systems can't represent this timestamp at all (so they're safe), but I don't know what would be the best way to conditionally compile here.
compat/gmtime.c | 10 ++++++++++ config.mak.uname | 1 + 2 files changed, 11 insertions(+)
diff --git a/compat/gmtime.c b/compat/gmtime.c index 75a5835..f95ba50 100644 --- a/compat/gmtime.c +++ b/compat/gmtime.c @@ -12,6 +12,16 @@ struct tm *git_gmtime_r(const time_t *timep, struct tm *result) { struct tm *ret; + /* + * Some systems, like AIX, will happily overflow the tm_year field. + * So let's recognize obviously out-of-bound data before it hits gmtime + * and just mark it as an error. This date is ~316 million years in the + * future, which is far enough that nobody should care, but close + * enough for the year to fit into a 32-bit tm_year. + */ + if (*timep > 9999999999999999LL) + return NULL; + ret = gmtime_r(timep, result); /* diff --git a/config.mak.uname b/config.mak.uname index 0e22ac0..c1110ad 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -236,6 +236,7 @@ ifeq ($(uname_S),AIX) INLINE = '' endif GIT_TEST_CMP = cmp + GMTIME_UNRELIABLE_ERRORS = UnfortunatelyYes endif ifeq ($(uname_S),GNU) # GNU/Hurd
-- 1.9.1.656.ge8a0637