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é
next prev 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).