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 <p...@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
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
@@ -12,6 +12,16 @@ struct tm *git_gmtime_r(const time_t *timep, struct tm
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
@@ -236,6 +236,7 @@ ifeq ($(uname_S),AIX)
INLINE = ''
GIT_TEST_CMP = cmp
+ GMTIME_UNRELIABLE_ERRORS = UnfortunatelyYes
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html