Re: [PATCH v2] strbuf: add and use strbuf_insertstr()
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Feb 9, 2020, 17:36 UTC
- Message-ID
- <CAPig+cQdJ0NJSWZN-2ckeLB7RfU9GZ7LGvVX4y+Q1daPnW8WsA@mail.gmail.com>
- 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:
Show 17 quoted lines
> 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.