From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: Stephen Boyd <bebarino@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] log-tree: fix patch filename computation in "git format-patch"
Date: Thu, 26 Mar 2009 21:15:39 -0700 [thread overview]
Message-ID: <7v3acziot0.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20090327011301.a5185805.chriscool@tuxfamily.org> (Christian Couder's message of "Fri, 27 Mar 2009 01:13:01 +0100")
Christian Couder <chriscool@tuxfamily.org> writes:
> When using "git format-patch", "get_patch_filename" in
> "log-tree.c" calls "strbuf_splice" that could die with
> the following message:
>
> "`pos + len' is too far after the end of the buffer"
>
> if you have:
>
> buf->len < start_len + FORMAT_PATCH_NAME_MAX
>
> but:
>
> buf->len + suffix_len > start_len + FORMAT_PATCH_NAME_MAX
>
> This patch tries to get rid of that bug.
hmm, tries to?
> diff --git a/log-tree.c b/log-tree.c
> index 56a3488..ade79ab 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -187,16 +187,17 @@ void get_patch_filename(struct commit *commit, int nr, const char *suffix,
>
> strbuf_addf(buf, commit ? "%04d-" : "%d", nr);
> if (commit) {
> + int max_len = start_len + FORMAT_PATCH_NAME_MAX;
> format_commit_message(commit, "%f", buf, DATE_NORMAL);
> /*
> * Replace characters at the end with the suffix if the
> * filename is too long
> */
> + if (buf->len + suffix_len > max_len) {
> + int base = (max_len > buf->len) ? buf->len : max_len;
> + strbuf_splice(buf, base - suffix_len, suffix_len,
> + suffix, suffix_len);
> + } else
> strbuf_addstr(buf, suffix);
Your third argument to splice does not look right; if the existing length
is very very long, you would need to remove a lot, and if the existing
length is slightly long, you would need to remove just a little bit, but
you always seem to remove the fixed amount, to splice the suffix in.
In any case, why does this have to be so complex?
In your buffer, you originally have start_len, and would want to end up
with "%f" expansion, plus the suffix, but you are not allowed to exceed
FORMAT_PATCH_NAME_MAX to store what you add, and are only allowed to chop
the "%f" expansion if you are short of room.
Shouldn't it be just:
size_t max_len = start_len + FORMAT_PATCH_NAME_MAX - suffix_len;
if (max_len < buf->len)
strbuf_setlen(buf, max_len);
strbuf_addstr(buf, suffix);
The caller must make sure that suffix_len is sufficiently shorter than
FORMAT_PATCH_NAME_MAX; I do not know if the current code does that,
though.
next prev parent reply other threads:[~2009-03-27 4:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 0:13 [PATCH] log-tree: fix patch filename computation in "git format-patch" Christian Couder
2009-03-27 4:15 ` Junio C Hamano [this message]
2009-03-27 4:31 ` Stephen Boyd
2009-03-27 7:15 ` Christian Couder
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=7v3acziot0.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=bebarino@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.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).