On Thu, Jul 14, 2016 at 10:52:55PM +0200, Johannes Sixt wrote: > > Dscho? I'll revert the merge of 'js/t0006-for-v2.9.2' out of > > 'next' so that we can replace it with your newer version, but it > > needs to be massaged to lose the strong linkage with "time", as > > it is no longer "is our time big enough", I would think. > > My first thought was that this is not warranted because t0006 is about > commit time stamps, but the huge-tar breakage is file sizes, and the cases > should be treated differently. > > But on second thought, under the hood, both boil down to the size of > unsigned long in our implementation. It may make sense to tie both cases to > the same prerequisite. > > On third thought, however, I think the two requirements could diverge in the > future. The file size case should depend on the size of size_t. The > timestamp case may become dependent on the size of time_t if we decide to > move timestamp handling away from unsigned long: in modern(!) Microsoft > SDKs, time_t is 64 bits, but unsigned long is 32 bits, in both the 32-bit > and 64-bit environments! The tar tests actually cover both: big files and big timestamps. I think as long as the prereq is labeled LONG_IS_64BIT, we can then adjust the appropriate tests if and when they become runnable on more systems. If we move to time_t everywhere, I think we'll need an extra TIME_T_IS_64BIT, but we can cross that bridge when we come to it. Likewise I think we'll need SIZE_T_IS_64BIT eventually (for real 32-bit systems; LLP64 systems like Windows will then be able to run the test). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html