All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>, Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH v2] strbuf: add and use strbuf_insertstr()
Date: Sun, 9 Feb 2020 12:36:22 -0500	[thread overview]
Message-ID: <CAPig+cQdJ0NJSWZN-2ckeLB7RfU9GZ7LGvVX4y+Q1daPnW8WsA@mail.gmail.com> (raw)
In-Reply-To: <b31c46a8-380b-3528-27a5-a2dddacaf837@web.de>

On Sun, Feb 9, 2020 at 8:45 AM René Scharfe <l.s.r@web.de> wrote:
> Add a function for inserting a C string into a strbuf.  Use it
> throughout the source to get rid of magic string length constants and
> explicit strlen() calls.
>
> Like strbuf_addstr(), implement it as an inline function to avoid the
> implicit strlen() calls to cause runtime overhead.
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> diff --git a/mailinfo.c b/mailinfo.c
> @@ -570,7 +570,7 @@ static int check_header(struct mailinfo *mi,
>                 len = strlen("Content-Type: ");
>                 strbuf_add(&sb, line->buf + len, line->len - len);
>                 decode_header(mi, &sb);
> -               strbuf_insert(&sb, 0, "Content-Type: ", len);
> +               strbuf_insertstr(&sb, 0, "Content-Type: ");
>                 handle_content_type(mi, &sb);

Meh. We've already computed the length of "Content-Type: " a few lines
earlier, so taking advantage of that value when inserting the string
literal is perfectly sensible. Thus, I'm not convinced that this
change is an improvement.

Digging deeper, though, I have to wonder why this bothers inserting
"Content-Type: " at all. None of the other cases handled by
check_header() bother re-inserting the header, so why this one? I
thought it might be because handle_content_type() depends upon the
header being present, but from my reading, this does not appear to be
the case. handle_content_type() calls has_attr_value() and
slurp_attr() to examine the incoming line, but neither of those seem
to expect any sort of "<Header>: " either. Thus, it appears that the
insertion of "Content-Type: " is superfluous. If this is indeed the
case, then rather than converting this to strbuf_insertstr(), I could
see it being pulled out into a separate patch which merely removes the
strbuf_insert() call.

  reply	other threads:[~2020-02-09 17:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-08 19:56 [PATCH] strbuf: add and use strbuf_insertstr() René Scharfe
2020-02-08 23:08 ` Taylor Blau
2020-02-09 10:23   ` René Scharfe
2020-02-09  0:53 ` Eric Sunshine
2020-02-09 10:23   ` René Scharfe
2020-02-09 13:44 ` [PATCH v2] " René Scharfe
2020-02-09 17:36   ` Eric Sunshine [this message]
2020-02-09 18:28     ` René Scharfe
2020-02-09 21:09       ` Eric Sunshine
2020-02-09 23:10       ` Taylor Blau
2020-02-10 23:44     ` Jeff King
2020-02-11 16:17       ` Junio C Hamano
2020-02-11 17:16         ` [PATCH 0/4] some more mailinfo cleanups Jeff King
2020-02-11 17:18           ` [PATCH 1/4] mailinfo: treat header values as C strings Jeff King
2020-02-11 17:26             ` Eric Sunshine
2020-02-11 17:19           ` [PATCH 2/4] mailinfo: simplify parsing of header values Jeff King
2020-02-11 17:19           ` [PATCH 3/4] mailinfo: be more liberal with header whitespace Jeff King
2020-02-11 17:20           ` [PATCH 4/4] mailinfo: factor out some repeated header handling Jeff King
2020-02-11 16:18       ` [PATCH v2] strbuf: add and use strbuf_insertstr() René Scharfe
2020-02-11 17:13         ` Jeff King
2020-02-10  7:15   ` [PATCH 2/1] mailinfo: don't insert header prefix for handle_content_type() René Scharfe
2020-02-10 17:27     ` Junio C Hamano
2020-02-10 19:55     ` 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=CAPig+cQdJ0NJSWZN-2ckeLB7RfU9GZ7LGvVX4y+Q1daPnW8WsA@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=me@ttaylorr.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.