Re: [PATCH 5/5] log: do not segfault on gmtime errors

From: Jeff King <peff@peff.net>
Date: Mar 26, 2014, 18:21 UTC
Message-ID: <20140326182103.GB7087@sigill.intra.peff.net>
In-Reply-To: <20140326110559.GA32625@hashpling.org>

On Wed, Mar 26, 2014 at 11:05:59AM +0000, Charles Bailey wrote:

Show 12 quoted lines

> On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
> > +# date is within 2^63-1, but enough to choke glibc's gmtime
> > +test_expect_success 'absurdly far-in-future dates produce sentinel' '
> > +	commit=$(munge_author_date HEAD 999999999999999999) &&
> > +	echo "Thu Jan 1 00:00:00 1970 +0000" >expect &&
> > +	git log -1 --format=%ad $commit >actual &&
> > +	test_cmp expect actual
> > +'
> 
> Git on AIX seems happy to convert this to Thu Oct 24 18:46:39
> 162396404 -0700. I don't know if this is correct for the given input
> but the test fails.

Ick. I am not sure that dates at that range are even meaningful (will October really exist in the year 162396404? Did they account for all the leap-seconds between then and now?). But at the same time, I cannot fault their gmtime for just extrapolating the current rules out as far as we ask them to.

Unlike the FreeBSD thing that René brought up, this is not a problem in the code, but just in the test. So I think our options are basically:

  1. Scrap the test as unportable.

  2. Hard-code a few expected values. I'd be unsurprised if some other
     system comes up with a slightly different date in 162396404, so we
     may end up needing several of these.

I think I'd lean towards (2), just because it is testing an actual feature of the code, and I'd like to continue doing so. And while we may end up with a handful of values, there's probably not _that_ many independent implementations of gmtime in the wild.

-Peff