All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Ivan Lyapunov <dront78@gmail.com>,
	git@vger.kernel.org, Antoine Pelisse <apelisse@gmail.com>
Subject: Re: git log - crash and core dump
Date: Wed, 17 Apr 2013 19:59:28 +0200	[thread overview]
Message-ID: <516EE300.7020200@lsrfire.ath.cx> (raw)
In-Reply-To: <20130417063942.GA27703@sigill.intra.peff.net>

Am 17.04.2013 08:39, schrieb Jeff King:
> On Tue, Apr 16, 2013 at 10:26:40PM -0700, Junio C Hamano wrote:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>>
>>>> How about making split_ident_line() a bit friendlier be letting it
>>>> provide the epoch as default time stamp instead of NULL?
>>>
>>> Two knee-jerk concerns I have without going back to the callers:
>>>
>>>   * Would that "0" ever be given to the approxidate parser, which
>>>     rejects ancient dates in numbers-since-epoch format without @
>>>     prefix?
>>>
>>>   * Does any existing caller use the NULL as a sign to see the input
>>>     was without date and act on that information?
>>
>> I looked at all the callers (there aren't that many), and none of
>> them did "Do this on a person-only ident, and do that on an ident
>> with timestamp".  So for the callers that ignore timestamp, your
>> patch will be a no-op, and for others that assume there is a
>> timestamp, it will turn a crash/segv into output with funny
>> timestamp.
>
> What about sane_ident_split in builtin/commit.c? It explicitly rejects a
> NULL date. The logic in determine_author_info is a little hard to follow
> (it assembles the ident line with fmt_ident and then reparses it), but I
> believe it should be catching a bogus line from "commit -c", or from
> GIT_AUTHOR_DATE in the environment.

Right, so let's keep the NULLs and fix the individual cases.  A quick
"git grep -W -e date_begin -e date_end -e tz_begin -e tz_end" reveals
that there are only the ones we talked about: blame, pretty, commit
and -- of course -- ident.  And only the first two need fixing.

> As a side note, when determine_author_info sees a bogus ident, it
> appears to just silently ignore it, which is probably a bad thing.
> Shouldn't we by complaining?  Or am I mis-reading the code?

The code looks complicated, but I just tried it: fmt_ident() dies if you 
give it an invalid date.

René

  parent reply	other threads:[~2013-04-17 17:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 16:55 git log - crash and core dump Ivan Lyapunov
2013-04-16 17:29 ` Antoine Pelisse
2013-04-16 18:09 ` René Scharfe
2013-04-16 19:45   ` Junio C Hamano
2013-04-16 21:10     ` René Scharfe
2013-04-16 22:21       ` Junio C Hamano
2013-04-17  2:50         ` Ivan Lyapunov
2013-04-17  5:22           ` Ivan Lyapunov
2013-04-17  8:27             ` John Keeping
2013-04-17  9:14               ` Ivan Lyapunov
2013-04-17  9:43                 ` Konstantin Khomoutov
     [not found]                   ` <CANKwXW1heci+D5ZO3aF+dMN9davRawuZuKz0bf2n3iRiMjjgHg@mail.gmail.com>
2013-04-17 10:23                     ` Ivan Lyapunov
2013-04-17  5:26         ` Junio C Hamano
2013-04-17  6:39           ` Jeff King
2013-04-17 17:51             ` Junio C Hamano
2013-04-17 17:59             ` René Scharfe [this message]
2013-04-17 18:02               ` Jeff King
2013-04-17 19:06                 ` René Scharfe
2013-04-17 21:00                   ` [PATCH] cat-file: print tags raw for "cat-file -p" Jeff King
2013-04-19  3:03                     ` Eric Sunshine
2013-04-17 18:33               ` [PATCH] pretty: handle broken commit headers gracefully René Scharfe
2013-04-17 18:33               ` [PATCH] blame: " René Scharfe
2013-04-17 21:07                 ` Jeff King
2013-04-17 21:22                   ` René Scharfe
2013-04-17 21:55                   ` Junio C Hamano
2013-04-18 16:56                     ` Jeff King
2013-04-16 21:24     ` git log - crash and core dump Antoine Pelisse
2013-04-16 21:34     ` 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=516EE300.7020200@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=apelisse@gmail.com \
    --cc=dront78@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.