git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: "René Scharfe" <l.s.r@web.de>
Cc: Junio C Hamano <gitster@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH] fetch: convert strncmp() with strlen() to starts_with()
Date: Tue, 27 Feb 2024 08:58:09 +0100	[thread overview]
Message-ID: <Zd2WEeR4fBmbbZFo@tanuki> (raw)
In-Reply-To: <08db9346-d10d-4b32-ae55-3ee5a8adf89d@web.de>

[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]

On Mon, Feb 26, 2024 at 09:04:27PM +0100, René Scharfe wrote:
> Am 26.02.24 um 18:11 schrieb Junio C Hamano:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >>> -		     !strncmp(rs->items[i].src,
> >>> -			      ref_namespace[NAMESPACE_TAGS].ref,
> >>> -			      strlen(ref_namespace[NAMESPACE_TAGS].ref)))) {
> >>> +		     starts_with(rs->items[i].src,
> >>> +				 ref_namespace[NAMESPACE_TAGS].ref))) {
> >>
> >> The original tries to check that "namespace" fully matches the
> >> initial part of .src string, which is exactly what starts_with()
> >> does.  Makes sense.
> >
> > There are two more such instances in the codebase, easily found with
> >
> >         $ cat >contrib/coccinelle/starts_with.cocci <<\-EOF
> >         @@
> >         expression string, prefix;
> >         @@
> >         - !strncmp(string, prefix, strlen(prefix))
> >         + starts_with(string, prefix)
> >
> >         @@
> >         expression string, prefix;
> >         @@
> >         - strncmp(string, prefix, strlen(prefix))
> >         + !starts_with(string, prefix)
> >         EOF
> >         $ make contrib/coccinelle/starts_with.cocci.patch
> >
> > which finds the one you just fixed (naturally, since the Cocci patch
> > was written by taking inspiration from your fix).
> >
> > Here is one in the reftable code.  The other one is in xdiff/ I'd
> > rather not touch (as starts_with() is probably not available there).
> 
> Indeed, starts_with() is not available in xdiff/xpatience.c.  That whole
> file is a Git-specific extension to libxdiff, though.  We could add an
> include or copy the function definition.

It's kind of the same for the reftable library code. It's in this weird
in-between state where it's supposed to be usable as a library, but it
already does use some of Git's infra. I would personally be happy to use
more bits of the Git library in the reftable library, but we do need to
acknowledge that this makes it harder for other projects to use the
code.

So we should think about how we want to proceed here:

  - Is the reftable library now a part of the Git codebase that can use
    all of the features that we already have?

  - Is the reftable library an independent part that has the goal of
    being reusable for other projects?

With the ongoing libification project I certainly think that the first
option becomes more viable, as we can essentially have the best of both
worlds. The reftable library can be reused by other projects, and at the
same time we can use our own internals. But it's still going to take
quite some time until that can be fully realized, I assume.

Patrick

> It might make sense for performance reasons alone if there are lots of
> anchors or they are very long, as with starts_with() we no longer would
> have to call strlen() on all of them for each line to diff.  Never used
> the anchored diff algorithm, though, so I don't know whether that's a
> problem in practice.
> 
> >
> > diff -u -p a/reftable/refname.c b/reftable/refname.c
> > --- a/reftable/refname.c
> > +++ b/reftable/refname.c
> > @@ -103,7 +103,7 @@ static int modification_has_ref_with_pre
> >  			}
> >  		}
> >
> > -		if (strncmp(ref.refname, prefix, strlen(prefix))) {
> > +		if (!starts_with(ref.refname, prefix)) {
> >  			err = 1;
> >  			goto done;
> >  		}
> 
> 
> That file has another one with reversed argument order:
> 
> diff --git a/reftable/refname.c b/reftable/refname.c
> index 7570e4acf9..10fc8b872d 100644
> --- a/reftable/refname.c
> +++ b/reftable/refname.c
> @@ -78,8 +78,7 @@ static int modification_has_ref_with_prefix(struct modification *mod,
>  			.want = prefix,
>  		};
>  		int idx = binsearch(mod->add_len, find_name, &arg);
> -		if (idx < mod->add_len &&
> -		    !strncmp(prefix, mod->add[idx], strlen(prefix)))
> +		if (idx < mod->add_len && starts_with(mod->add[idx], prefix))
>  			goto done;
>  	}
>  	err = reftable_table_seek_ref(&mod->tab, &it, prefix);
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2024-02-27  7:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-24 21:47 [PATCH] fetch: convert strncmp() with strlen() to starts_with() René Scharfe
2024-02-24 23:45 ` Junio C Hamano
2024-02-26 17:11   ` Junio C Hamano
2024-02-26 20:04     ` René Scharfe
2024-02-27  7:58       ` Patrick Steinhardt [this message]

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=Zd2WEeR4fBmbbZFo@tanuki \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    /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).