t0006 & t5000: prepare for 64-bit timestamps

Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers. That is why the `time_t` data type exists: so that it can be 64-bit even if `long` is 32-bit. Git's source code simply uses an incorrect data type for timestamps, is all. The earlier quick fix 6b9c38e14cd (t0006: skip "far in the future" test when unsigned long is not long enough, 2016-07-11) papered over this issue simply by skipping the respective test cases on platforms where they would fail due to the data type in use. This quick fix, however, tests for *long* to be 64-bit or not. What we need, though, is a test that says whether *whatever data type we use for timestamps* is 64-bit or not. The same quick fix was used to handle the similar problem where Git's source code uses `unsigned long` to represent size, instead of `size_t`, conflating the two issues. So let's just add another prerequisite to test specifically whether timestamps are represented by a 64-bit data type or not. Later, after we switch to a larger data type, we can flip that prerequisite to test `time_t` instead of `long`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Johannes Schindelin committed Apr 20, 2017 at 22:52 UTC a07fb0507fdf745704e54d77aa19780580636f56
4 files changed +11 -6
t/helper/test-date.c
+4 -1
@@ -4,7 +4,8 @@ static const char *usage_msg = "\n"
4 " test-date relative [time_t]...\n"
5 " test-date show:<format> [time_t]...\n"
6 " test-date parse [date]...\n"
7 -" test-date approxidate [date]...\n";
7 +" test-date approxidate [date]...\n"
8 +" test-date is64bit\n";
9
10 static void show_relative_dates(const char **argv, struct timeval *now)
11 {
@@ -93,6 +94,8 @@ int cmd_main(int argc, const char **argv)
94 parse_dates(argv+1, &now);
95 else if (!strcmp(*argv, "approxidate"))
96 parse_approxidate(argv+1, &now);
97 + else if (!strcmp(*argv, "is64bit"))
98 + return sizeof(unsigned long) == 8 ? 0 : 1;
99 else
100 usage(usage_msg);
101 return 0;
t/t0006-date.sh
+2 -2
@@ -53,8 +53,8 @@ check_show unix-local "$TIME" '1466000000'
53
54 # arbitrary time absurdly far in the future
55 FUTURE="5758122296 -0400"
56 -check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" LONG_IS_64BIT
57 -check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" LONG_IS_64BIT
56 +check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" TIME_IS_64BIT
57 +check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" TIME_IS_64BIT
58
59 check_parse() {
60 echo "$1 -> $2" >expect
t/t5000-tar-tree.sh
+3 -3
@@ -390,7 +390,7 @@ test_expect_success TAR_HUGE,LONG_IS_64BIT 'system tar can read our huge size' '
390 test_cmp expect actual
391 '
392
393 -test_expect_success LONG_IS_64BIT 'set up repository with far-future commit' '
393 +test_expect_success TIME_IS_64BIT 'set up repository with far-future commit' '
394 rm -f .git/index &&
395 echo content >file &&
396 git add file &&
@@ -398,11 +398,11 @@ test_expect_success LONG_IS_64BIT 'set up repository with far-future commit' '
398 git commit -m "tempori parendum"
399 '
400
401 -test_expect_success LONG_IS_64BIT 'generate tar with future mtime' '
401 +test_expect_success TIME_IS_64BIT 'generate tar with future mtime' '
402 git archive HEAD >future.tar
403 '
404
405 -test_expect_success TAR_HUGE,LONG_IS_64BIT 'system tar can read our future mtime' '
405 +test_expect_success TAR_HUGE,TIME_IS_64BIT 'system tar can read our future mtime' '
406 echo 4147 >expect &&
407 tar_info future.tar | cut -d" " -f2 >actual &&
408 test_cmp expect actual
t/test-lib.sh
+2
@@ -1164,3 +1164,5 @@ build_option () {
1164 test_lazy_prereq LONG_IS_64BIT '
1165 test 8 -le "$(build_option sizeof-long)"
1166 '
1167 +
1168 +test_lazy_prereq TIME_IS_64BIT 'test-date is64bit'