git.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).