path: root/builtin/receive-pack.c
diff options
authorJohannes Schindelin <>2017-04-20 20:52:13 (GMT)
committerJunio C Hamano <>2017-04-21 05:07:15 (GMT)
commita07fb0507fdf745704e54d77aa19780580636f56 (patch)
treef0c8b7f6e8a73da1a94ffe7edfe9c1cd9e7a42e9 /builtin/receive-pack.c
parente467dc148d0375ed83300589281f749fcbdd690d (diff)
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 <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'builtin/receive-pack.c')
0 files changed, 0 insertions, 0 deletions