[PATCH 4/5] 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>
---
A note on these tests. They are designed for 64-bit systems, but should
run fine on 32-bit systems (they are both just overflow, and the second
test is not doing anything novel that the first is not).

However, the second test relies on finding a value that fits into an "unsigned long" but does not fit into a time_t. For systems with a 64-bit signed time_t, that's fine. But if a system has an unsigned 64-bit time_t, the test will fail (it will actually produce some value 300 billion years from now).

I'm inclined to include it as-is, as I do not know of any such system (and it would be kind of lame, since it could not represent dates before 1970). If somebody comes up with such a system, we can allow either output (we could do it preemptively, but somebody would have to calculate the exact date/time billions of years in the future; we would be just as likely to disagree with the system's gmtime about something silly like leapseconds).

 pretty.c               | 10 ++++++++--
 t/t4212-log-corrupt.sh | 16 ++++++++++++++++
 2 files changed, 24 insertions(+), 2 deletions(-)