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

[Taylor Blau <me@ttaylorr.com>]

On Sun, Feb 09, 2020 at 07:28:31PM +0100, René Scharfe wrote:
> 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.

Yes, if 'strbuf_insertstr' weren't inlined, I'd be less eager to make
this suggestion, but since it *is* inlined, I don't think that the
compiler will generate substantially different instructions whether we
use one or the other here.

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

Agreed.

> > 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)?

I certainly can't speak for Eric, but for my $.02 I don't think that
it's worth holding this series up. This seems like a separate issue to
me, and I'd rather it not get get in the way of a perfectly good patch
in the meantime.

For now, this increases the churn a little bit, but that is the price
we have to pay for the new 'strbuf_insertstr' to be applied/used
consistently.

I'd be happy to see this go further, but I'd be just as happy to stop
where we're at.

> Thanks,
> René

Thanks,
Taylor