All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Alban Gruin <alban.gruin@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 1/3] parse_insn_line(): improve error message when parsing failed
Date: Fri, 17 Jan 2020 10:00:08 -0800	[thread overview]
Message-ID: <xmqqmuamdkuv.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <2ae2e435b0ef6888e72defc7abee1909b29aa914.1579209506.git.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Thu, 16 Jan 2020 21:18:24 +0000")

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> In the case that a `get_oid()` call failed, we showed some rather bogus
> part of the line instead of the precise string we sent to said function.
> That makes it rather hard for users to understand what is going wrong,
> so let's fix that.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  sequencer.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index b9dbf1adb0..7c30dad59c 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -2118,6 +2118,8 @@ static int parse_insn_line(struct repository *r, struct todo_item *item,
>  	saved = *end_of_object_name;
>  	*end_of_object_name = '\0';
>  	status = get_oid(bol, &commit_oid);
> +	if (status < 0)
> +		error(_("could not parse '%s'"), bol); /* return later */
>  	*end_of_object_name = saved;

OK, so after making sure the line begins a command that takes an
object name, we first NUL terminated the token after the command
but it turns out the string is not a valid oid.  We show the part
we thought was the object name before reverting the NUL termination.

Makes sense.  And then later...

>  	bol = end_of_object_name + strspn(end_of_object_name, " \t");
> @@ -2125,11 +2127,10 @@ static int parse_insn_line(struct repository *r, struct todo_item *item,
>  	item->arg_len = (int)(eol - bol);
>  
>  	if (status < 0)
> -		return error(_("could not parse '%.*s'"),
> -			     (int)(end_of_object_name - bol), bol);
> +		return status;

...this is the *only* code that uses the status that was assigned to
the return value of get_oid().  

Because the implementation of this function (mis)uses "bol", which
stands for "beginning of line", as a moving pointer of "beginning of
the token we are looking at", the value of "bol" at this point of
the control in the original code is not where the "bol" pointer used
to be when end-of-object-name was computed (if it were, the '%.*s'
argument would have been correct) and shows a token after where the
object name would have been, which may help the user identify the
line but does not directly show what token we had trouble with
parsing.

And the updated code will avoid the issue by using the "bol" pointer
when it is still pointing at the right place.


>  	item->commit = lookup_commit_reference(r, &commit_oid);
> -	return !item->commit;
> +	return item->commit ? 0 : -1;

This changes the polarity of the error exit from positive 1 to
negative 1.  The only caller of this function takes anything
non-zero as a failure so this would not cause behaviour change, but
returning negative is more in line with the practice so it is an
improvement (it is unrelated to the theme of this patch and is not
explained, though).

OK.


  reply	other threads:[~2020-01-17 18:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 21:18 [PATCH 0/3] Re-fix rebase -i with SHA-1 collisions Johannes Schindelin via GitGitGadget
2020-01-16 21:18 ` [PATCH 1/3] parse_insn_line(): improve error message when parsing failed Johannes Schindelin via GitGitGadget
2020-01-17 18:00   ` Junio C Hamano [this message]
2020-01-16 21:18 ` [PATCH 2/3] rebase -i: re-fix short SHA-1 collision Johannes Schindelin via GitGitGadget
2020-01-17 18:30   ` Junio C Hamano
2020-01-17 21:31     ` Johannes Schindelin
2020-01-16 21:18 ` [PATCH 3/3] rebase -i: also avoid SHA-1 collisions with missingCommitsCheck Johannes Schindelin via GitGitGadget
2020-01-16 23:54 ` [PATCH 0/3] Re-fix rebase -i with SHA-1 collisions brian m. carlson
2020-01-17  9:51   ` Johannes Schindelin
2020-01-17 22:37     ` brian m. carlson
2020-01-21 18:00       ` Junio C Hamano
2020-01-17 23:38 ` [PATCH v2 " Johannes Schindelin via GitGitGadget
2020-01-17 23:38   ` [PATCH v2 1/3] parse_insn_line(): improve error message when parsing failed Johannes Schindelin via GitGitGadget
2020-01-21 22:04     ` Junio C Hamano
2020-01-23 12:26       ` Johannes Schindelin
2020-01-17 23:38   ` [PATCH v2 2/3] rebase -i: re-fix short SHA-1 collision Johannes Schindelin via GitGitGadget
2020-01-20 16:49     ` Eric Sunshine
2020-01-20 20:04       ` Johannes Schindelin
2020-01-20 20:08         ` Eric Sunshine
2020-01-21 11:49           ` Johannes Schindelin
2020-01-21 22:02           ` Junio C Hamano
2020-01-22 14:10             ` Johannes Schindelin
2020-01-22 18:15               ` Junio C Hamano
2020-01-17 23:38   ` [PATCH v2 3/3] rebase -i: also avoid SHA-1 collisions with missingCommitsCheck Johannes Schindelin via GitGitGadget
2020-01-23 12:28   ` [PATCH v3 0/3] Re-fix rebase -i with SHA-1 collisions Johannes Schindelin via GitGitGadget
2020-01-23 12:28     ` [PATCH v3 1/3] parse_insn_line(): improve error message when parsing failed Johannes Schindelin via GitGitGadget
2020-01-23 12:28     ` [PATCH v3 2/3] rebase -i: re-fix short SHA-1 collision Johannes Schindelin via GitGitGadget
2020-01-23 12:28     ` [PATCH v3 3/3] rebase -i: also avoid SHA-1 collisions with missingCommitsCheck Johannes Schindelin via GitGitGadget

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=xmqqmuamdkuv.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=alban.gruin@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=sandals@crustytoothpaste.net \
    --cc=sunshine@sunshineco.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.