On Wed, Mar 26, 2014 at 02:01:21PM -0700, Junio C Hamano wrote:
> > I don't know how important that is. This is such a minor feature that it
> > is not worth a lot of maintenance headache in the test. But I also do
> > not know if this is going to be the last report, or we will have a bunch
> > of
Jeff King writes:
> On Wed, Mar 26, 2014 at 11:58:49AM -0700, Junio C Hamano wrote:
>
>> > Unlike the FreeBSD thing that René brought up, this is not a problem in
>> > the code, but just in the test. So I think our options are basically:
>> >
>> > 1. Scrap the test as unportable.
>> >
>> > 2.
On Wed, Mar 26, 2014 at 11:58:49AM -0700, Junio C Hamano wrote:
> > Unlike the FreeBSD thing that René brought up, this is not a problem in
> > the code, but just in the test. So I think our options are basically:
> >
> > 1. Scrap the test as unportable.
> >
> > 2. Hard-code a few expected val
Jeff King writes:
> On Wed, Mar 26, 2014 at 11:05:59AM +, Charles Bailey wrote:
>
>> On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
>> > +# date is within 2^63-1, but enough to choke glibc's gmtime
>> > +test_expect_success 'absurdly far-in-future dates produce sentinel' '
>> > +
On Wed, Mar 26, 2014 at 11:05:59AM +, Charles Bailey wrote:
> On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
> > +# date is within 2^63-1, but enough to choke glibc's gmtime
> > +test_expect_success 'absurdly far-in-future dates produce sentinel' '
> > + commit=$(munge_author_dat
On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
> +# date is within 2^63-1, but enough to choke glibc's gmtime
> +test_expect_success 'absurdly far-in-future dates produce sentinel' '
> + commit=$(munge_author_date HEAD 99) &&
> + echo "Thu Jan 1 00:00:00 1970 +00
On Mon, Mar 24, 2014 at 11:03:42PM +0100, René Scharfe wrote:
> >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
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)
-
On Sat, Mar 22, 2014 at 10:32:37AM +0100, René Scharfe wrote:
> >This test is of questionable portability, since we are depending on
> >gmtime's arbitrary point to decide that our input is crazy and return
> >NULL. The value is sufficiently large that I'd expect most to do so,
> >though, so it may
Am 24.02.2014 08:49, schrieb Jeff King:
Many code paths assume that show_date and show_ident_date
cannot return NULL. For the most part, we handle missing or
corrupt timestamps by showing the epoch time t=0.
However, we might still return NULL if gmtime rejects the
time_t we feed it, resulting i
Many code paths assume that show_date and show_ident_date
cannot return NULL. For the most part, we handle missing or
corrupt timestamps by showing the epoch time t=0.
However, we might still return NULL if gmtime rejects the
time_t we feed it, resulting in a segfault. Let's catch this
case and ju
11 matches
Mail list logo
