Jeff King p...@peff.net writes:
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.
On Mon, Feb 24, 2014 at 11:50:00AM -0800, Junio C Hamano wrote:
We also recognize overflow in the timezone field, which
could produce nonsensical results. In this case we show the
parsed date, but in UTC.
Both are good measures to fallback to sanity, but why is that
if/else? In other
Jeff King p...@peff.net writes:
On Mon, Feb 24, 2014 at 11:50:00AM -0800, Junio C Hamano wrote:
We also recognize overflow in the timezone field, which
could produce nonsensical results. In this case we show the
parsed date, but in UTC.
Both are good measures to fallback to sanity, but
On Mon, Feb 24, 2014 at 12:21:33PM -0800, Junio C Hamano wrote:
+if (date_overflows(date))
+date = 0;
+else {
+if (ident-tz_begin ident-tz_end)
+tz = strtol(ident-tz_begin, NULL, 10);
+if
Jeff King p...@peff.net writes:
On Mon, Feb 24, 2014 at 12:21:33PM -0800, Junio C Hamano wrote:
+ if (date_overflows(date))
+ date = 0;
+ else {
+ if (ident-tz_begin ident-tz_end)
+ tz = strtol(ident-tz_begin, NULL,
5 matches
Mail list logo
