Jeff King <p...@peff.net> writes:
>> 9999999999999999 Sat Jan 25 10:46:39 316889355 -0700
>> 99999999999999999 Wed Sep 6 02:46:39 -1126091476 -0700
>> 999999999999999999 Thu Oct 24 18:46:39 1623969404 -0700
>
> Thanks. Given the value where it fails, it kind of looks like there is
> some signed 32-bit value at work (~300 million years is OK, but 10 times
> that, rather than yielding ~3 billion, gets us -1 billion). Perhaps
> tm.tm_year is 32-bit.
That is what it looks like to me, too. It makes me wonder if some
other platforms may have similar breakage using 16-bit signed
tm_year and how such a breakage would look like, though ;-)
> So what do we want to do? I think the options are:
>
> 1. Try to guess when we have a bogus timestamp value with an arbitrary
> cutoff like "greater than 1 million years from now" (and enforce it
> via time_t seconds, and avoid gmtime entirely). That is made-up and
> arbitrary, but it also is sufficiently far that it won't ever
> matter, and sufficiently close that any gmtime should behave
> sensibly with it.
I think that two assumptions here are that
(1) we would be able to find a single insane value (like 3 billion
years from now expressed in time_t seconds) the test script
would be able to feed and expect it to fail on all platforms we
care about, even though how exactly that value causes various
platforms fail may be different (glibc may give us a NULL from
gmtime, FreeBSD may leave their own sentinel in gmtime we can
recognize, and some others may simply wrap around the years);
and that
(2) the only other class of failure mode we haven't considered
bevore Charles's report is tm_year wrapping around 32-bit
signed int.
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
- Use that 3-billion years timestamp from Charles's report in the
test and make sure we convert it to the known sentinel value.
perhaps?
> 2. Accept that we can't guess at every broken gmtime's output, and
> just loosen the test to make sure we don't segfault.
Of course that is a simpler option, but we may have identified all
plausible failure modes, in which case we can afford to go with your
original plan to validate that we not just avoid segfaulting on one
of the three failure modes from gmtime, but also cover the other two
failure modes and signal any of them with a sentinel. That way may
allow us to identify the fourth failure mode we haven't anticipated.
--
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
