From: Jeff King Date: Mon, 24 Feb 2014 07:46:37 +0000 (-0500) Subject: log: handle integer overflow in timestamps X-Git-Tag: v1.9.1~4^2~2 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/1dca155fe3fac29e847d2d8ff1087d892a129a9c?ds=inline;hp=1dca155fe3fac29e847d2d8ff1087d892a129a9c 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 Signed-off-by: Junio C Hamano ---