Re: [ANNOUNCE] Git v2.9.1

From: Jeff King <peff@peff.net>
Date: Jul 12, 2016, 15:16 UTC
Message-ID: <20160712151630.GE613@sigill.intra.peff.net>
In-Reply-To: <xmqqpoqj6i3d.fsf@gitster.mtv.corp.google.com>

On Tue, Jul 12, 2016 at 07:34:14AM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> > Git's source code assumes that unsigned long is at least as precise as
> > time_t. Well, Git's source code is wrong.
> > ...
> 
> That is correct.  As people mentioned downthread already, "unsigned
> long" has two problems, it may not be wide enough, and it cannot
> represent time before the epoch.
> 
> But moving the internal time representation used in various fields
> like commit->date to time_t is likely to be a wrong thing to do,
> because the first problem with "unsigned long", i.e. "may not be
> wide enough", is not limited to "not wide enough to hold time_t".
> It also includes "it may not be wide enough to hold time somebody
> else recorded in existing objects".

But that's a problem no matter what size we choose. The ascii format in the commit objects is arbitrary-length, so somebody can always overflow it. So even with intmax_t we have to clamp it to a sentinel value at some point. IMHO we are better off to do so at parse time, and then have consistent sizes through the rest of the code base, without worrying about juggling intmax_t to time_t truncation in multiple places.

IOW, I think we probably interact with the system time libraries more often than we parse (and it's easy to wrap the parsing in a function, but there are a lot of system time functions).

-Peff