From: "René Scharfe" <l.s.r@web.de>
To: Eric Sunshine <sunshine@sunshineco.com>
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 19:28:31 +0100 [thread overview]
Message-ID: <60b491a1-2b71-d5a5-398f-e6743e2c617a@web.de> (raw)
In-Reply-To: <CAPig+cQdJ0NJSWZN-2ckeLB7RfU9GZ7LGvVX4y+Q1daPnW8WsA@mail.gmail.com>
Am 09.02.20 um 18:36 schrieb Eric Sunshine:
> 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.
Well, yes, but it would be more sensible if we'd have only a single
string here. At the source code level we have two string constants that
happen to have the same contents. Handling them separately is
reasonable, I think.
The compiler is merging those two, and resolves the other strlen() call
at compile time, so the generated code is the same.
> Thus, I'm not convinced that this change is an improvement.
The improvement is to untangle the handling of those two string
constants and to use a C string without having to pass along its
length. That doesn't make the code clean, yet, admittedly.
> 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.
Interesting. It makes sense that handle_content_type() wouldn't need
such a header prefix -- it's only called if its existence in the line
has been confirmed. And I also don't see a hint in the code that
would justify the insertion.
Do you care to send a follow-up patch (or one against master if you're
not convinced by my reasoning given above)?
Thanks,
René
next prev parent reply other threads:[~2020-02-09 18:28 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
2020-02-09 18:28 ` René Scharfe [this message]
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=60b491a1-2b71-d5a5-398f-e6743e2c617a@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--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 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).