From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "René Scharfe" <l.s.r@web.de>, "Duy Nguyen" <pclouds@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH 2/9] add strip_suffix function
Date: Wed, 02 Jul 2014 08:54:44 -0700 [thread overview]
Message-ID: <xmqqlhsbiwmz.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140630165751.GB16637@sigill.intra.peff.net> (Jeff King's message of "Mon, 30 Jun 2014 12:57:51 -0400")
Jeff King <peff@peff.net> writes:
> For that reason, the "mem" form puts its length parameter
> next to the buffer (since they are a pair), and the string
> form puts it at the end (since it is an out-parameter). The
> compiler can notice when you get the order wrong, which
> should help prevent writing one when you meant the other.
Very sensible consideration. I like commits that careful thinking
behind them shows through them.
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I hope the word "strip" is OK, as it does not actually NUL-terminate
> (doing so would make it unusable for many cases). Between the comment
> below and the "const" in the parameter, I think it should be pretty
> clear that it does not touch the string. And I could not think of a
> better word.
All other words I can think of offhand, trim, chomp, etc., hint
shortening of the input string, and by definition shortening of a
string implies NUL-termination.
The "mem" variant deals with a counted string, however, so its
shortening implies NUL-termination a lot less [*1*] and should be
fine.
If we want to avoid implying NUL-termination, the only way to do so
would be to use wording that does not hint shortening. At least for
the C-string variant, which is measuring the length of the basename
part (i.e. `basename $str $suffix`) without touching anything else,
e.g. basename_length("hello.c", ".c", &len), but at the same time
you want to make it a boolean to signal if the string ends with the
suffix, so perhaps has_suffix("hello.c", ".c", &len)?
[Footnote]
*1* ... but not entirely, because we often NUL-terminate even
counted strings (the buffer returned from read_sha1_file() and
the payload of strbuf are two examples).
> git-compat-util.h | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index b6f03b3..d044c42 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -358,6 +358,33 @@ static inline const char *skip_prefix(const char *str, const char *prefix)
> return NULL;
> }
>
> +/*
> + * If buf ends with suffix, return 1 and subtract the length of the suffix
> + * from *len. Otherwise, return 0 and leave *len untouched.
> + */
> +static inline int strip_suffix_mem(const char *buf, size_t *len,
> + const char *suffix)
> +{
> + size_t suflen = strlen(suffix);
> + if (*len < suflen || memcmp(buf + (*len - suflen), suffix, suflen))
> + return 0;
> + *len -= suflen;
> + return 1;
> +}
> +
> +/*
> + * If str ends with suffix, return 1 and set *len to the size of the string
> + * without the suffix. Otherwise, return 0 and set *len to the size of the
> + * string.
> + *
> + * Note that we do _not_ NUL-terminate str to the new length.
> + */
> +static inline int strip_suffix(const char *str, const char *suffix, size_t *len)
> +{
> + *len = strlen(str);
> + return strip_suffix_mem(str, len, suffix);
> +}
> +
> #if defined(NO_MMAP) || defined(USE_WIN32_MMAP)
>
> #ifndef PROT_READ
next prev parent reply other threads:[~2014-07-02 15:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-28 14:47 [PATCH 1/2] sha1_file: replace PATH_MAX buffer wirh strbuf in prepare_packed_git_one() René Scharfe
2014-06-28 15:01 ` [PATCH 2/4] sha1_file: use strncmp for string comparison René Scharfe
2014-06-29 1:21 ` [PATCH 1/2] sha1_file: replace PATH_MAX buffer wirh strbuf in prepare_packed_git_one() Duy Nguyen
2014-06-29 5:43 ` [PATCH v2 1/2] sha1_file: replace PATH_MAX buffer wirh strbuf in, prepare_packed_git_one() René Scharfe
2014-06-29 5:56 ` [PATCH v2 2/2] sha1_file: use strncmp for string comparison René Scharfe
2014-06-30 13:43 ` Jeff King
2014-06-30 13:59 ` Duy Nguyen
2014-06-30 14:22 ` Jeff King
2014-06-30 16:43 ` René Scharfe
2014-06-30 16:45 ` Jeff King
2014-06-30 16:35 ` René Scharfe
2014-06-30 16:46 ` Jeff King
2014-06-30 16:55 ` [PATCH 0/9] add strip_suffix as an alternative to ends_with Jeff King
2014-06-30 16:55 ` [PATCH 1/9] sha1_file: replace PATH_MAX buffer with strbuf in prepare_packed_git_one() Jeff King
2014-06-30 16:57 ` [PATCH 2/9] add strip_suffix function Jeff King
2014-07-02 15:54 ` Junio C Hamano [this message]
2014-07-02 16:38 ` Jeff King
2014-07-02 17:41 ` Junio C Hamano
2014-06-30 16:58 ` [PATCH 3/9] implement ends_with via strip_suffix Jeff King
2014-06-30 16:58 ` [PATCH 4/9] replace has_extension with ends_with Jeff King
2014-06-30 16:58 ` [PATCH 5/9] use strip_suffix instead of ends_with in simple cases Jeff King
2014-06-30 16:59 ` [PATCH 6/9] index-pack: use strip_suffix to avoid magic numbers Jeff King
2014-06-30 17:01 ` [PATCH 7/9] strbuf: implement strbuf_strip_suffix Jeff King
2014-06-30 17:02 ` [PATCH 8/9] verify-pack: use strbuf_strip_suffix Jeff King
2014-06-30 17:04 ` [PATCH 9/9] prepare_packed_git_one: refactor duplicate-pack check Jeff King
2014-07-01 1:00 ` [PATCH 0/9] add strip_suffix as an alternative to ends_with Junio C Hamano
2014-06-30 13:24 ` [PATCH v2 1/2] sha1_file: replace PATH_MAX buffer wirh strbuf in, prepare_packed_git_one() Jeff King
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=xmqqlhsbiwmz.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
/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.