[ Trying to come up with crazy special cases ]
On Wed, Jul 11, 2018 at 1:49 PM Linus Torvalds
<torva...@linux-foundation.org> wrote:
>
> But it could be anything else invalid, of course. It could be MAX_INT
> or something like that.
That might be better. A timezone of -1 isn't actually a valid
timezone, but I guess you could create a commit by hand that had
"-0001" as the timezone.
You can't do that with something like MAX_INT, without fsck
complaining - since it has to be exactly four digits.
> The clearing of "human_tm" is done for a similar reason: the code does
>
> hide.year = tm->tm_year == human_tm->tm_year;
>
> (and then later just checks "if (human_tm->tm_year)") knowing that a
> non-zero tm_year will only ever happen for human_tz (and that 1900 is
> not a valid git date, even though I guess in theory you could do it).
Actually, the 1900 should be safe, because 'timestamp_t' is unsigned.
So a valid timestamp really can't be before 1970.
Of course, you can probably try to mess with it by giving values that
don't actually fit, because sometimes we do convert mindlessly from
'timestamp_t' to 'time_t'. In particular, if you use the
"default-local" time, it will use that
static struct tm *time_to_tm_local(timestamp_t time)
{
time_t t = time;
return localtime(&t);
}
and not check the range of the timestamp.
But other proper time stamp functions will actually do range checking
with "date_overflow()", so in general that whole assumption of "a real
git date cannot be in the year 1900" is valid.
Linus
