From: René Scharfe <l.s.r@web.de>
Date: Mon, 24 Mar 2014 22:03:42 GMT
Subject: Re: [PATCH 5/5] log: do not segfault on gmtime errors
Message-ID: <5330ABBE.3080106@web.de>
In-Reply-To: <20140324213342.GE13728@sigill.intra.peff.net>

Am 24.03.2014 22:33, schrieb Jeff King:
> On Sat, Mar 22, 2014 at 10:32:37AM +0100, René Scharfe wrote:
>>> @@ -184,8 +184,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
>>>   		tz = local_tzoffset(time);
>>>
>>>   	tm = time_to_tm(time, tz);
>>> -	if (!tm)
>>> -		return NULL;
>>> +	if (!tm) {
>>
>> Would it make sense to work around the FreeBSD issue by adding a check like
>> this?
>>
>> 	if (!tm || tm->tm_year < 70) {
>
> That feels like a bit of a maintenance headache.  Right now we do not
> internally represent times prior to the epoch, since we mostly use
> "unsigned long" through the code. So anything < 70 has to be an error.
> But it would be nice one day to consistently use a 64-bit signed time_t
> throughout git, and represent even ancient timestamps (e.g., for people
> doing historical projects, like importing laws into git). This would set
> quite a trap for people working later on the code.
>
> If the result is all-zeroes, can we check for that case instead? I
> suppose that will eventually create a "trap" at midnight on January 1st
> of the year 0 (though I am not sure such a date is even meaningful,
> given the history of our calendars).

Makes sense. That would be "Sun Jan 0 00:00:00 1900", however -- days 
are 1-based and years 1900-based in struct tm.  Since a zeroth day is 
invalid, would this suffice:

	if (!tm || !tm->tm_mday) {

(Yes, I'm lazy. :)

René