All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Charles Bailey <cbailey32@bloomberg.net>, git@vger.kernel.org
Subject: Re: [PATCH 5/5] log: do not segfault on gmtime errors
Date: Wed, 26 Mar 2014 14:01:21 -0700	[thread overview]
Message-ID: <xmqqeh1oisim.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140326190157.GB12912@sigill.intra.peff.net> (Jeff King's message of "Wed, 26 Mar 2014 15:01:58 -0400")

Jeff King <peff@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. Hard-code a few expected values. I'd be unsurprised if some other
>> >      system comes up with a slightly different date in 162396404, so we
>> >      may end up needing several of these.
>> >
>> > I think I'd lean towards (2), just because it is testing an actual
>> > feature of the code, and I'd like to continue doing so. And while we may
>> > end up with a handful of values, there's probably not _that_ many
>> > independent implementations of gmtime in the wild.
>> 
>> Or "3. Just make sure that 'git log' does not segfault"?
>
> That would not test the FreeBSD case, which does not segfault, but
> returns a bogus sentinel value.
>
> 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 systems that need their own special values put into the test.

I didn't quite realize that your objective of the change was to
signal the failure of gmtime for all implementations, i.e. both (1)
the ones that signal an error by giving NULL back to us and (2) the
ones that fail to signal an error but leave bogus result (FreeBSD,
but it appears AIX might be also giving us another bogus value), by
using a single sane sentinel value.  If we can do that consistently
on every platform, that would indeed be great.

But if that is the case, we should not have to maintain special case
values in the test code, I would think.  The test instead should
expect the output to have that single sentinel value, and if the
workaround code fails to detect a breakage in the platform gmtime(),
the special case logic to catch these platform-specific breakages
should go that "timestamp that cannot be grokked by gmtime---replace
it with a sentinel" logic, no?

  reply	other threads:[~2014-03-26 21:01 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
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 [this message]
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=xmqqeh1oisim.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=cbailey32@bloomberg.net \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.