diff options
author | Jeff King <peff@peff.net> | 2014-02-24 11:46:37 +0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-02-24 22:12:58 +0400 |
commit | 1dca155fe3fac29e847d2d8ff1087d892a129a9c (patch) | |
tree | 05e4d112c5893403f7ec5614914ae4469a070b1b /date.c | |
parent | 7ca36d9398a85e7974d04f8fbd2c6adb088290e1 (diff) |
log: handle integer overflow in timestamps
If an ident line has a ridiculous date value like (2^64)+1,
we currently just pass ULONG_MAX along to the date code,
which can produce nonsensical dates.
On systems with a signed long time_t (e.g., 64-bit glibc
systems), this actually doesn't end up too bad. The
ULONG_MAX is converted to -1, we apply the timezone field to
that, and the result ends up somewhere between Dec 31, 1969
and Jan 1, 1970.
However, there is still a few good reasons to detect the
overflow explicitly:
1. On systems where "unsigned long" is smaller than
time_t, we get a nonsensical date in the future.
2. Even where it would produce "Dec 31, 1969", it's easier
to recognize "midnight Jan 1" as a consistent sentinel
value for "we could not parse this".
3. Values which do not overflow strtoul but do overflow a
signed time_t produce nonsensical values in the past.
For example, on a 64-bit system with a signed long
time_t, a timestamp of 18446744073000000000 produces a
date in 1947.
We also recognize overflow in the timezone field, which
could produce nonsensical results. In this case we show the
parsed date, but in UTC.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'date.c')
0 files changed, 0 insertions, 0 deletions