Jeff King <p...@peff.net> writes:
> On Fri, Mar 28, 2014 at 09:41:53AM -0700, Junio C Hamano wrote:
>
>> Offhand, the three possible failure modes this thread identified
>> sounds to me like the only plausible ones, and I think the best way
>> forward might be to
>>
>> - teach the "is the result sane, even though we may have got a
>> non-NULL from gmtime? otherwise let's signal a failure by
>> replacing it with a known sentinel value" codepath the new
>> failure mode Charles's report suggests---if we feed a positive
>> timestamp and gmtime gave us back a tm_year+1900 < 0, that is
>> certainly an overflow; and
>
> I don't think we can analyze the output from gmtime. If it wraps the
> year at N, then won't N+2014 look like a valid value?
Yes, but I was hoping that there are small number of possible N's
;-)
> If we are going to do something trustworthy I think it has to be before
> we hand off to gmtime. Like:
>
> diff --git a/date.c b/date.c
> index e1a2cee..e0c43c4 100644
> --- a/date.c
> +++ b/date.c
> @@ -57,6 +57,8 @@ static time_t gm_time_t(unsigned long time, int tz)
> static struct tm *time_to_tm(unsigned long time, int tz)
> {
> time_t t = gm_time_t(time, tz);
> + if (t > 9999999999999999)
> + return NULL;
> return gmtime(&t);
> }
>
> I suspect that would handle the FreeBSD case, as well.
>
> By the way, I have a suspicion that the gm_time_t above can overflow if
> you specially craft a value at the edge of what time_t can handle (we
> check that our value will not overflow time_t earlier, but now we might
> be adding up to 86400 seconds to it). <sigh>
Yuck. Let's not go there.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
