Re: [ANNOUNCE] Git v2.9.1

From: Jeff King <peff@peff.net>
Date: Jul 12, 2016, 07:39 UTC
Message-ID: <20160712073912.GA26431@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1607120927410.6426@virtualbox>

On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote:

Show 7 quoted lines

> On Mon, 11 Jul 2016, Junio C Hamano wrote:
> 
> > Those who care about 32-bit builds need to start building and
> > testing 'next' and 'master' regularly, or similar breakages are
> > bound to continue happening X-<.
> 
> Please note that "unsigned long" is 32-bit even on 64-bit Windows.

Yeah, that was part of the reason my run-time test checked sizeof(unsigned long), and not any kind of "are we 64-bit?" compiler options or output. So the "64BIT" prereq is actually a bit of a misnomer; it is really "is your ULL 64-bit, because that's what we use for time". :-/

> FWIW I have this monster patch as a starting point (I plan to work more on
> this today):

Cool! Thanks for working on this.

I suspect we should still do something about skipping those tests, though, if only because the v2.9.x maint track is broken, and switching to time_t is a sufficiently large change that we probably don't want it for maint (it _seems_ like it shouldn't cause any problems, but I'm wondering if we might inadvertently trigger funny issues around signedness or something).

Show 7 quoted lines

> From b65de5a56e18b038d432ba828d7714880b8e285c Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date: Tue, 12 Jul 2016 09:09:07 +0200
> Subject: [PATCH] HOTFIX: use time_t wherever appropriate
> 
> Git's source code assumes that unsigned long is at least as precise as
> time_t. Well, Git's source code is wrong.

Another problem with "unsigned long" is that we cannot handle times older than 1970. Assuming most systems are sane enough to have a signed time_t these days, this would fix that problem as well.

-Peff