All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [RFH] renaming strcmp/strncmp-icase
Date: Mon, 08 Sep 2014 21:31:02 +0200	[thread overview]
Message-ID: <540E03F6.3010100@web.de> (raw)
In-Reply-To: <xmqqmwaalzb4.fsf@gitster.dls.corp.google.com>

On 2014-09-08 20.52, Junio C Hamano wrote:
> There are these two functions in dir.c that has only a handful of
> callers outside:
> 
>     int strcmp_icase(const char *a, const char *b);
>     int strncmp_icase(const char *a, const char *b, size_t count);
> 
> How many of you would think these are about comparing two strings in
> a case-insensitive way?
> 
> If you raised your hand (like I did), you were wrong.  These do
> comparison case-insensitively only on a case-insensitive filesystem,
> and hence calling it makes sense only for pathnames you grabbed out
> of the filesystem via readdir() (or the user gave us, intending to
> name paths).
> 
> To avoid confusion, I think they should be renamed to stress the
> fact that these are about comparing *PATHS*.  As I always say, I am
> bad at naming things and good suggestions are appreciated.
> 
> FYI, there are names I thought about and haven't managed to convince
> myself that they are good.
> 
> A good name for the non-n variant may be "compare_paths()", but that
> is used in "combine-diff.c".  "compare_pathnames()" may be a
> compromise.
> 
> However, either of these makes it hard to come up with a
> corresponding name for the "n" (counted) variant.  The best I could
> do was "compare_pathnames_counted()", but a nice similarity to
> strcmp()/strncmp() pair is lost.
> 
> pathnamecmp()/pathnamencmp() perhaps?
> 
> I dunno.
And then we have this in name-hash.c:
(Which may explain the "icase" suffix ?)

static int same_name(const struct cache_entry *ce, const char *name, int namelen, int icase)
{
	int len = ce_namelen(ce);

	/*
	 * Always do exact compare, even if we want a case-ignoring comparison;
	 * we do the quick exact one first, because it will be the common case.
	 */
	if (len == namelen && !memcmp(name, ce->name, len))
		return 1;

	if (!icase)
		return 0;

	return slow_same_name(name, namelen, ce->name, len);
}

-----------
static int slow_same_name(const char *name1, int len1, const char *name2, int len2)
{
	if (len1 != len2)
		return 0;

	while (len1) {
		unsigned char c1 = *name1++;
		unsigned char c2 = *name2++;
		len1--;
		if (c1 != c2) {
			c1 = toupper(c1);
			c2 = toupper(c2);
			if (c1 != c2)
				return 0;
		}
	}
	return 1;
}

  reply	other threads:[~2014-09-08 19:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 18:52 [RFH] renaming strcmp/strncmp-icase Junio C Hamano
2014-09-08 19:31 ` Torsten Bögershausen [this message]
2014-09-08 19:56   ` Junio C Hamano
2014-09-08 21:36 ` René Scharfe

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=540E03F6.3010100@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.