git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Vasil Dimov via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Vasil Dimov <vd@freebsd.org>
Subject: Re: [PATCH 2/2] range-diff: avoid negative string precision
Date: Wed, 15 Apr 2020 10:20:35 -0600	[thread overview]
Message-ID: <20200415162035.GD22823@syl.local> (raw)
In-Reply-To: <b3384880c7201d65adb7341ce23386d578e69193.1586960921.git.gitgitgadget@gmail.com>

On Wed, Apr 15, 2020 at 02:28:41PM +0000, Vasil Dimov via GitGitGadget wrote:
> From: Vasil Dimov <vd@FreeBSD.org>
>
> If the supplied integer for "precisoin" is negative in

s/precisoin/precision

> `"%.*s", len, line` then it is ignored. So the current code is
> equivalent to just `"%s", line` because it is executed only if
> `len` is negative.
>
> Fix this by saving the value of `len` before overwriting it with the
> return value of `parse_git_diff_header()`.
>
> Signed-off-by: Vasil Dimov <vd@FreeBSD.org>
> ---
>  range-diff.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/range-diff.c b/range-diff.c
> index 5cc920be391..40af0862818 100644
> --- a/range-diff.c
> +++ b/range-diff.c
> @@ -123,16 +123,19 @@ static int read_patches(const char *range, struct string_list *list,
>  			struct patch patch = { 0 };
>  			struct strbuf root = STRBUF_INIT;
>  			int linenr = 0;
> +			int orig_len;

Any reason to not assign this to 'len' up here?
>
>  			in_header = 0;
>  			strbuf_addch(&buf, '\n');
>  			if (!util->diff_offset)
>  				util->diff_offset = buf.len;
>  			line[len - 1] = '\n';
> +			orig_len = len;
>  			len = parse_git_diff_header(&root, &linenr, 0, line,
>  						    len, size, &patch);

OK, so we cut up the line by placing a NL at len, and then feed it to
'parse_git_diff_header' which will tell us the length of the thing that
it parsed, or give a negative value if it couldn't parse...

>  			if (len < 0)
> -				die(_("could not parse git header '%.*s'"), (int)len, line);
> +				die(_("could not parse git header '%.*s'"),
> +				    orig_len, line);

...and then you restore the original length and print it out here. It
seems like this error is now misleading though, because the line is
already modified at the point that the newline was inserted.

>  			strbuf_addstr(&buf, " ## ");
>  			if (patch.is_new > 0)
>  				strbuf_addf(&buf, "%s (new)", patch.new_name);
> --
> gitgitgadget

Thanks,
Taylor

  reply	other threads:[~2020-04-15 16:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 14:28 [PATCH 0/2] range-diff: fix a crash in parsing git-log output Vasil Dimov via GitGitGadget
2020-04-15 14:28 ` [PATCH 1/2] " Vasil Dimov via GitGitGadget
2020-04-15 15:31   ` Junio C Hamano
2020-04-15 16:16     ` Vasil Dimov
2020-04-15 16:23     ` Jeff King
2020-04-15 22:02       ` Taylor Blau
2020-04-15 22:29         ` Jeff King
2020-04-15 16:13   ` Taylor Blau
2020-04-15 14:28 ` [PATCH 2/2] range-diff: avoid negative string precision Vasil Dimov via GitGitGadget
2020-04-15 16:20   ` Taylor Blau [this message]
2020-04-15 20:19     ` Vasil Dimov
2020-04-15 20:32 ` [PATCH v2 0/2] range-diff: fix a crash in parsing git-log output Vasil Dimov via GitGitGadget
2020-04-15 20:32   ` [PATCH v2 1/2] " Vasil Dimov via GitGitGadget
2020-04-15 20:32   ` [PATCH v2 2/2] range-diff: avoid negative string precision Vasil Dimov via GitGitGadget
2020-04-16  1:07   ` [PATCH v2 0/2] range-diff: fix a crash in parsing git-log output Taylor Blau

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=20200415162035.GD22823@syl.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=vd@freebsd.org \
    /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).