From: Junio C Hamano <gitster@pobox.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] Clean up builtin-update-ref's option parsing
Date: Sun, 25 May 2008 11:40:24 -0700 [thread overview]
Message-ID: <7vk5hii5wn.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 20080525161435.25087.82683.stgit@yoghurt
Karl Hasselström <kha@treskal.com> writes:
> builtin-update-ref's option parsing was somewhat tricky to follow,
> especially if the -d option was given. This patch cleans it upp a bit
> (including fixing an out-of-bounds argv access), at the expense of
> making it a bit longer.
>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
Longer is fine but I am afraid that this patch is not much easier to
follow than the original, does not fix anything, and introduces a new bug.
> diff --git a/builtin-update-ref.c b/builtin-update-ref.c
> index e90737c..0d3eb8e 100644
> --- a/builtin-update-ref.c
> +++ b/builtin-update-ref.c
> @@ -27,25 +27,29 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
> if (msg && !*msg)
> die("Refusing to perform update with empty message.");
>
> - if (argc < 2 || argc > 3)
> - usage_with_options(git_update_ref_usage, options);
> - refname = argv[0];
> - value = argv[1];
> - oldval = argv[2];
> -
> - if (get_sha1(value, sha1))
> - die("%s: not a valid SHA1", value);
> -
> if (delete) {
> - if (oldval)
> + if (argc != 2)
> usage_with_options(git_update_ref_usage, options);
> - return delete_ref(refname, sha1);
> + refname = argv[0];
> + value = NULL;
> + oldval = argv[1];
> + } else {
> + if (argc < 2 || argc > 3)
> + usage_with_options(git_update_ref_usage, options);
> + refname = argv[0];
> + value = argv[1];
> + oldval = argc > 2 ? argv[2] : NULL;
When (argc == 3), argv[2] has the old value string given on the command
line. When (argc == 2), argv[2] has the terminating NULL pointer. So
either case you can safely use argv[2]. You do not allow other cases
upfront, so I do not understand why you need this conditional expression?
IOW, I do not see "an out-of-bounds argv access" in the original, and you
are making this assignment harder to follow.
> }
>
> + if (value && *value && get_sha1(value, sha1))
> + die("%s: not a valid SHA1", value);
Dropping *value in the sequence may fix it but I think this is wrong.
We used to barf if you said "git update-ref refs/heads/master '' master"
because it would be nonsense to give an empty string as the new value of
the ref, didn't we? Doesn't this change break it? Does your set of
additional tests in [1/3] catch it?
> hashclr(oldsha1);
> if (oldval && *oldval && get_sha1(oldval, oldsha1))
> die("%s: not a valid old SHA1", oldval);
>
> - return update_ref(msg, refname, sha1, oldval ? oldsha1 : NULL,
> - no_deref ? REF_NODEREF : 0, DIE_ON_ERR);
> + if (delete)
> + return delete_ref(refname, oldsha1);
> + else
> + return update_ref(msg, refname, sha1, oldval ? oldsha1 : NULL,
> + no_deref ? REF_NODEREF : 0, DIE_ON_ERR);
> }
next prev parent reply other threads:[~2008-05-25 18:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-25 16:14 [PATCH 0/3] Make old sha1 optional with git update-ref -d Karl Hasselström
2008-05-25 16:14 ` [PATCH 1/3] Add some tests for " Karl Hasselström
2008-05-25 16:14 ` [PATCH 2/3] Clean up builtin-update-ref's option parsing Karl Hasselström
2008-05-25 18:40 ` Junio C Hamano [this message]
2008-05-25 19:32 ` Karl Hasselström
2008-06-02 23:34 ` [PATCH v2 0/2] Make old sha1 optional with git update-ref -d Karl Hasselström
2008-06-02 23:34 ` [PATCH v2 1/2] Clean up builtin-update-ref's option parsing Karl Hasselström
2008-06-02 23:34 ` [PATCH v2 2/2] Make old sha1 optional with git update-ref -d Karl Hasselström
2008-06-03 5:51 ` Junio C Hamano
2008-06-03 6:49 ` Karl Hasselström
2008-06-03 19:39 ` Junio C Hamano
2008-05-25 16:14 ` [PATCH 3/3] " Karl Hasselström
2008-05-26 10:51 ` Johannes Schindelin
2008-05-26 14:09 ` Karl Hasselström
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=7vk5hii5wn.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kha@treskal.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 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).