On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote: > 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). > From b65de5a56e18b038d432ba828d7714880b8e285c Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin <johannes.schinde...@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 -- 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
