Johannes Sixt <j6t@xxxxxxxx> writes: > 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! I had the same three toughts, but this being a 'maint' material stopped me going too deep into them. Right now, "long being 32-bit" is the source of all of these issues, and we would solve them on the development track (not necessarily during this cycle) by deciding on more appropriate types. Timestamps may become time_t, and object sizes may become off_t, such changes will come separately, and each of them would need to lift "unless long is 64-bit, skip this test" limitation and swap it with something else. -- 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