Re: [PATCH v2] strbuf: add and use strbuf_insertstr()

> 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.

> 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.