All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Charles Bailey <cbailey32@bloomberg.net>, git@vger.kernel.org
Subject: Re: [PATCH] t4212: handle systems with post-apocalyptic gmtime
Date: Wed, 26 Mar 2014 15:25:36 -0400	[thread overview]
Message-ID: <20140326192536.GA13989@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqr45oixa6.fsf@gitster.dls.corp.google.com>

On Wed, Mar 26, 2014 at 12:18:25PM -0700, Junio C Hamano wrote:

> > +		echo "$candidate" >expect &&
> > +		test_cmp expect actual &&
> > +		return 0
> > +	done
> > +	return 1
> > +}
> 
> It actually may be easier to understand if you write a trivial case
> statement at the sole calling site of this helper function, though.

Yeah, perhaps. I wanted to build on test_cmp because it has nice output
for the failure case, but it is probably simple enough to do:

  output=$(cat actual)
  case "$output" in
  ...
  *) echo >&2 "unrecognized date: $output"

> In any case, would it really be essential to make sure that the
> output shows a phony (or a seemingly real) datestamp for this test?
> 
> The primary thing you wanted to achieve by the "gmtime gave us NULL,
> let's substitute it with an arbitrary value to avoid dereferencing
> the NULL" change was *not* that we see that same arbitrary value
> comes out of the system, but that we do not die by attempting to
> reference the NULL, I think.  Not dying is the primary thing we want
> to (and we already do) test, no?

I think there are really two separate behaviors we are testing here (and
in the surrounding tests):

  1. Don't segfault if gmtime returns NULL.

  2. Whenever we cannot process a date (either because gmtime fails, or
     because we fail before even getting the value to gmtime),
     consistently return the sentinel date (so the reader can easily
     know it's bogus).

Having the test be particular about its output helped us find a case
where FreeBSD did not trigger (1), but did trigger (2), by returning a
blanked "struct tm".

I'm open to the argument that (2) is not worth worrying about that much
if it is a hassle to test. But I don't think it is that much hassle
(yet, anyway).

-Peff

  reply	other threads:[~2014-03-26 19:25 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-24  7:33 [PATCH 0/5] handle bogus commit dates Jeff King
2014-02-24  7:36 ` [PATCH 1/5] t4212: test bogus timestamps with git-log Jeff King
2014-02-24  7:39 ` [PATCH 2/5] fsck: report integer overflow in author timestamps Jeff King
2014-02-24  7:39 ` [PATCH 3/5] date: check date overflow against time_t Jeff King
2014-02-24  7:46 ` [PATCH 4/5] log: handle integer overflow in timestamps Jeff King
2014-02-24 19:50   ` Junio C Hamano
2014-02-24 19:58     ` Jeff King
2014-02-24 20:21       ` Junio C Hamano
2014-02-24 20:37         ` Jeff King
2014-02-24 21:01           ` Junio C Hamano
2014-02-24  7:49 ` [PATCH 5/5] log: do not segfault on gmtime errors Jeff King
2014-03-22  9:32   ` René Scharfe
2014-03-24 21:33     ` Jeff King
2014-03-24 22:03       ` René Scharfe
2014-03-24 22:11         ` Jeff King
2014-03-26 11:05   ` Charles Bailey
2014-03-26 18:21     ` Jeff King
2014-03-26 18:51       ` [PATCH] t4212: handle systems with post-apocalyptic gmtime Jeff King
2014-03-26 19:18         ` Junio C Hamano
2014-03-26 19:25           ` Jeff King [this message]
2014-03-26 19:33             ` Jeff King
2014-03-26 19:40               ` Jeff King
2014-03-26 20:36                 ` Charles Bailey
2014-03-26 20:38                   ` Jeff King
2014-03-26 20:41                     ` Charles Bailey
2014-03-26 21:22               ` Charles Bailey
2014-03-26 21:57                 ` Jeff King
2014-03-26 22:46                   ` Charles Bailey
2014-03-27 22:48                     ` Jeff King
2014-03-28 16:41                       ` Junio C Hamano
2014-03-28 18:47                         ` Jeff King
2014-03-28 19:02                           ` Junio C Hamano
2014-03-28 19:05                             ` Jeff King
2014-03-28 19:30                               ` Junio C Hamano
2014-04-01  7:38                                 ` Jeff King
2014-04-01  7:42                                   ` [PATCH 1/2] date: recognize bogus FreeBSD gmtime output Jeff King
2014-04-01 17:42                                     ` René Scharfe
2014-04-01 19:08                                       ` Junio C Hamano
2014-04-01 21:17                                         ` René Scharfe
2014-04-01 21:28                                           ` Jeff King
2014-04-01  7:43                                   ` [PATCH 2/2] t4212: loosen far-in-future test for AIX Jeff King
2014-04-01  7:45                                   ` [PATCH 2alt/2] work around unreliable gmtime errors on AIX Jeff King
2014-04-01 19:07                                   ` [PATCH] t4212: handle systems with post-apocalyptic gmtime Junio C Hamano
2014-04-01 19:46                                     ` Jeff King
2014-03-26 18:58       ` [PATCH 5/5] log: do not segfault on gmtime errors Junio C Hamano
2014-03-26 19:01         ` Jeff King
2014-03-26 21:01           ` Junio C Hamano
2014-03-26 21:09             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140326192536.GA13989@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=cbailey32@bloomberg.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.