From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Eric Sunshine" <sunshine@sunshineco.com>,
孟子易 <mengziyi540841@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 3/3] shorten_unambiguous_ref(): avoid sscanf()
Date: Tue, 14 Feb 2023 13:48:57 -0800 [thread overview]
Message-ID: <xmqqmt5f535i.fsf@gitster.g> (raw)
In-Reply-To: <Y+vV8Ifkj1QV7KF0@coredump.intra.peff.net> (Jeff King's message of "Tue, 14 Feb 2023 13:41:52 -0500")
Jeff King <peff@peff.net> writes:
> +/*
> + * Check that the string refname matches a rule of the form
> + * "{prefix}%.*s{suffix}". So "foo/bar/baz" would match the rule
> + * "foo/%.*s/baz", and return the string "bar".
> + */
> +static const char *match_parse_rule(const char *refname, const char *rule,
> + size_t *len)
> +{
> + /*
> + * Check that rule matches refname up to the first percent
> + * in the rule. This is basically skip_prefix(), but
> + * ending at percent in the prefix, rather than end-of-string.
> + */
> + do {
> + if (!*rule)
> + BUG("rev-parse rule did not have percent");
> + if (*rule == '%')
> + break;
> + } while (*refname++ == *rule++);
So, if we have refname="refs/heads/frotz" and rule="refs/%.*s", then
we'll scan refname and rule to skip over their "refs/" prefix, and
the next iteration, where post-increment moved the pointers to point
at 'h' (at the beginning of "heads/frotz") on the refname side and
'%' on the rule side, we iterate once more, notice *rule is '%', and
break out of the loop. We have refname="heads/frotz" and rule="%.*s"
If we have refname="refsXheads/frotz" and rule="refs/%.*s", after
skipping over "refs", refname points at 'X' while rule points at '/'
and the loop needs to break. Both pointers are post-incremented,
and now we have refname="heads/frotz" and rule="%.*s".
Am I reading the loop correctly? I wanted the bogus refname not to
match the rule, but without peeking back refname[-1], I cannot tell
the two cases apart at this point.
> + /*
> + * Check that we matched all the way to the "%" placeholder,
> + * and skip past it within the rule string. If so, "refname" at
> + * this point is the beginning of a potential match.
> + */
> + if (!skip_prefix(rule, "%.*s", &rule))
> + return NULL;
And we now have rule pointing at "" (i.e. "refs/%.*s" has been fully
consumed). refname points at "heads/frotz".
> + /*
> + * And now check that our suffix (if any) matches.
> + */
> + if (!strip_suffix(refname, rule, len))
> + return NULL;
> +
> + return refname; /* len set by strip_suffix() */
> +}
And the suffix "" is stripped and we yield "heads/frotz".
next prev parent reply other threads:[~2023-02-14 21:49 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 6:38 bug report: symbolic-ref --short command echos the wrong text while use Chinese language 孟子易
2023-02-13 20:18 ` Jeff King
2023-02-13 22:58 ` Eric Sunshine
2023-02-14 1:39 ` Jeff King
2023-02-14 5:15 ` Eric Sunshine
2023-02-14 5:33 ` Eric Sunshine
2023-02-14 5:40 ` Junio C Hamano
2023-02-14 6:05 ` Eric Sunshine
2023-02-14 6:45 ` Junio C Hamano
2023-02-14 6:55 ` Eric Sunshine
2023-02-14 16:01 ` Jeff King
2023-02-14 16:29 ` Eric Sunshine
2023-02-14 17:07 ` Jeff King
2023-02-14 18:38 ` [PATCH 0/3] get rid of sscanf() when shortening refs Jeff King
2023-02-14 18:39 ` [PATCH 1/3] shorten_unambiguous_ref(): avoid integer truncation Jeff King
2023-02-14 18:40 ` [PATCH 2/3] shorten_unambiguous_ref(): use NUM_REV_PARSE_RULES constant Jeff King
2023-02-14 21:34 ` Junio C Hamano
2023-02-14 22:23 ` Jeff King
2023-02-14 18:41 ` [PATCH 3/3] shorten_unambiguous_ref(): avoid sscanf() Jeff King
2023-02-14 21:48 ` Junio C Hamano [this message]
2023-02-14 22:25 ` Junio C Hamano
2023-02-14 22:30 ` Jeff King
2023-02-14 22:34 ` Junio C Hamano
2023-02-14 22:40 ` Jeff King
2023-02-15 5:10 ` Junio C Hamano
2023-02-15 14:30 ` Jeff King
2023-02-15 16:41 ` Junio C Hamano
2023-02-14 23:20 ` Eric Sunshine
2023-02-15 15:16 ` [PATCH v2 0/3] get rid of sscanf() when shortening refs Jeff King
2023-02-15 15:16 ` [PATCH v2 1/3] shorten_unambiguous_ref(): avoid integer truncation Jeff King
2023-02-15 15:16 ` [PATCH v2 2/3] shorten_unambiguous_ref(): use NUM_REV_PARSE_RULES constant Jeff King
2023-02-15 15:16 ` [PATCH v2 3/3] shorten_unambiguous_ref(): avoid sscanf() Jeff King
2023-02-16 5:56 ` Torsten Bögershausen
2023-02-16 6:16 ` Eric Sunshine
2023-02-16 17:21 ` Junio C Hamano
2023-02-16 17:28 ` Jeff King
2023-02-16 23:36 ` Junio C Hamano
2023-02-16 17:31 ` Jeff King
2023-02-17 6:46 ` Torsten Bögershausen
2023-02-15 18:00 ` [PATCH v2 0/3] get rid of sscanf() when shortening refs Junio C Hamano
2023-02-14 16:40 ` bug report: symbolic-ref --short command echos the wrong text while use Chinese language Junio C Hamano
2023-02-14 17:40 ` Jeff King
2023-02-15 16:26 ` Torsten Bögershausen
2023-02-15 16:37 ` Eric Sunshine
2023-02-15 17:19 ` Torsten Bögershausen
2023-02-16 6:08 ` Eric Sunshine
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=xmqqmt5f535i.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mengziyi540841@gmail.com \
--cc=peff@peff.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.