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 +
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_date HEAD
Jeff King p...@peff.net 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: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 values. I'd be
Jeff King p...@peff.net 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 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 other
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 be
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 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 of our
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
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
11 matches
Mail list logo
