Re: [PATCH v4 0/9] Introduce timestamp_t for timestamps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Apr 23, 2017 at 08:29:11PM -0700, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> 
> > Changes since v3:
> >
> > - fixed the fix in archive-zip.c that tried to report a too large
> >   timestamp (and would have reported the uninitialized time_t instead)
> >
> > - adjusted the so-far forgotten each_reflog() function (that was
> >   introduced after v1, in 80f2a6097c4 (t/helper: add test-ref-store to
> >   test ref-store functions, 2017-03-26)) to use timestamp_t and PRItime,
> >   too
> >
> > - removed the date_overflows() check from time_to_tm(), as it calls
> >   gm_time_t() which already performs that check
> >
> > - the date_overflows() check in show_ident_date() was removed, as we do
> >   not know at that point yet whether we use the system functions to
> >   render the date or not (and there would not be a problem in the latter
> >   case)
> 
> Assuming that the list consensus is to go with a separate
> timestamp_t (for that added Cc for those whose comments I saw in an
> earlier round), the patches looked mostly good (I didn't read with
> fine toothed comb the largest one 6/8 to see if there were
> inadvertent or missed conversions from ulong to timestamp_t,
> though), modulo a few minor "huh?" comments I sent separately.
> 
> Will queue; thanks.

Sorry, I haven't read the series carefully yet (but from a skim I'm
happy with the overall direction). It does seem to cause failures in
t4212, though. For example:

  expecting success: 
  	commit=$(munge_author_date HEAD 18446744073709551617) &&
  	echo "Thu Jan 1 00:00:00 1970 +0000" >expect &&
  	git log -1 --format=%ad $commit >actual &&
  	test_cmp expect actual
  
  fatal: Timestamp too large for this system: 18446744073709551615
  not ok 7 - date parser recognizes integer overflow

We used to convert overflows into a sentinel time, but now we die. I
originally chose the sentinel approach because it lets you use the tools
to examine and recover from the broken state. I could be convinced that
dying is better, but clearly we'd need to at least update the tests.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]