git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
@ 2013-11-03 20:13 Christian Couder
  2013-11-04 17:56 ` Jonathan Nieder
  2013-11-04 19:19 ` Junio C Hamano
  0 siblings, 2 replies; 7+ messages in thread
From: Christian Couder @ 2013-11-03 20:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Avery Pennarun, Johannes Schindelin

Commit 8cc5b290 (git merge -X<option>, 25 Nov 2009) introduced
suffixcmp() with nearly the same implementation as postfixcmp()
that already existed since commit 211c8968 (Make git-remote a
builtin, 29 Feb 2008).

As postfixcmp() has always been static in builtin/remote.c
and is used nowhere else, it makes more sense to remove it
and use suffixcmp() instead in builtin/remote.c, rather than
to remove suffixcmp().

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 builtin/remote.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index 4e14891..9b3a98e 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -80,14 +80,6 @@ static int verbose;
 static int show_all(void);
 static int prune_remote(const char *remote, int dry_run);
 
-static inline int postfixcmp(const char *string, const char *postfix)
-{
-	int len1 = strlen(string), len2 = strlen(postfix);
-	if (len1 < len2)
-		return 1;
-	return strcmp(string + len1 - len2, postfix);
-}
-
 static int fetch_remote(const char *name)
 {
 	const char *argv[] = { "fetch", name, NULL, NULL };
@@ -277,13 +269,13 @@ static int config_read_branches(const char *key, const char *value, void *cb)
 		enum { REMOTE, MERGE, REBASE } type;
 
 		key += 7;
-		if (!postfixcmp(key, ".remote")) {
+		if (!suffixcmp(key, ".remote")) {
 			name = xstrndup(key, strlen(key) - 7);
 			type = REMOTE;
-		} else if (!postfixcmp(key, ".merge")) {
+		} else if (!suffixcmp(key, ".merge")) {
 			name = xstrndup(key, strlen(key) - 6);
 			type = MERGE;
-		} else if (!postfixcmp(key, ".rebase")) {
+		} else if (!suffixcmp(key, ".rebase")) {
 			name = xstrndup(key, strlen(key) - 7);
 			type = REBASE;
 		} else
-- 
1.8.4.1.576.g36ba827.dirty

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
  2013-11-03 20:13 [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead Christian Couder
@ 2013-11-04 17:56 ` Jonathan Nieder
  2013-11-04 19:19 ` Junio C Hamano
  1 sibling, 0 replies; 7+ messages in thread
From: Jonathan Nieder @ 2013-11-04 17:56 UTC (permalink / raw)
  To: Christian Couder; +Cc: Junio C Hamano, git, Avery Pennarun, Johannes Schindelin

Christian Couder wrote:

> Commit 8cc5b290 (git merge -X<option>, 25 Nov 2009) introduced
> suffixcmp() with nearly the same implementation as postfixcmp()
> that already existed since commit 211c8968 (Make git-remote a
> builtin, 29 Feb 2008).
[...]
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
>  builtin/remote.c | 14 +++-----------
>  1 file changed, 3 insertions(+), 11 deletions(-)

Makes sense.  Thanks for noticing.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
  2013-11-03 20:13 [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead Christian Couder
  2013-11-04 17:56 ` Jonathan Nieder
@ 2013-11-04 19:19 ` Junio C Hamano
  2013-11-04 20:16   ` Christian Couder
  2013-11-04 20:21   ` Junio C Hamano
  1 sibling, 2 replies; 7+ messages in thread
From: Junio C Hamano @ 2013-11-04 19:19 UTC (permalink / raw)
  To: Christian Couder; +Cc: git, Avery Pennarun, Johannes Schindelin

Christian Couder <chriscool@tuxfamily.org> writes:

> Commit 8cc5b290 (git merge -X<option>, 25 Nov 2009) introduced
> suffixcmp() with nearly the same implementation as postfixcmp()
> that already existed since commit 211c8968 (Make git-remote a
> builtin, 29 Feb 2008).

This "nearly the same" piqued my curiosity ;-)

The postfixcmp() you are removing will say "f" > ".txt" while
suffixcmp() will say "f" < ".txt".

As postfixcmp() is only used to compare for equality, the
distinction does not matter and does not affect the correctness of
this patch, but I am not sure which answer is more correct.

I do not think anybody sane uses prefixcmp() or suffixcmp() for
anything but checking with zero; in other words, I suspect that all
uses of Xcmp() can be replaced with !!Xcmp(), so as a separate
clean-up patch, we may at least want to make it clear that the
callers should not expect anything but "does str have sfx as its
suffix, yes or no?" by doing something like this:

 int suffixcmp(const char *str, const char *suffix)
 {
 	int len = strlen(str), suflen = strlen(suffix);
 	if (len < suflen)
 		return -1;
 	else
-		return strcmp(str + len - suflen, suffix);
+		return !!strcmp(str + len - suflen, suffix);
 }

I am not absolutely sure about doing the same to prefixcmp(),
though. It could be used for ordering, even though no existing code
seems to do so.

> As postfixcmp() has always been static in builtin/remote.c
> and is used nowhere else, it makes more sense to remove it
> and use suffixcmp() instead in builtin/remote.c, rather than
> to remove suffixcmp().
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
>  builtin/remote.c | 14 +++-----------
>  1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index 4e14891..9b3a98e 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -80,14 +80,6 @@ static int verbose;
>  static int show_all(void);
>  static int prune_remote(const char *remote, int dry_run);
>  
> -static inline int postfixcmp(const char *string, const char *postfix)
> -{
> -	int len1 = strlen(string), len2 = strlen(postfix);
> -	if (len1 < len2)
> -		return 1;
> -	return strcmp(string + len1 - len2, postfix);
> -}
> -
>  static int fetch_remote(const char *name)
>  {
>  	const char *argv[] = { "fetch", name, NULL, NULL };
> @@ -277,13 +269,13 @@ static int config_read_branches(const char *key, const char *value, void *cb)
>  		enum { REMOTE, MERGE, REBASE } type;
>  
>  		key += 7;
> -		if (!postfixcmp(key, ".remote")) {
> +		if (!suffixcmp(key, ".remote")) {
>  			name = xstrndup(key, strlen(key) - 7);
>  			type = REMOTE;
> -		} else if (!postfixcmp(key, ".merge")) {
> +		} else if (!suffixcmp(key, ".merge")) {
>  			name = xstrndup(key, strlen(key) - 6);
>  			type = MERGE;
> -		} else if (!postfixcmp(key, ".rebase")) {
> +		} else if (!suffixcmp(key, ".rebase")) {
>  			name = xstrndup(key, strlen(key) - 7);
>  			type = REBASE;
>  		} else

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
  2013-11-04 19:19 ` Junio C Hamano
@ 2013-11-04 20:16   ` Christian Couder
  2013-11-04 20:21   ` Junio C Hamano
  1 sibling, 0 replies; 7+ messages in thread
From: Christian Couder @ 2013-11-04 20:16 UTC (permalink / raw)
  To: gitster; +Cc: git, apenwarr, Johannes.Schindelin

From: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
Date: Mon, 04 Nov 2013 11:19:43 -0800

> Christian Couder <chriscool@tuxfamily.org> writes:
> 
>> Commit 8cc5b290 (git merge -X<option>, 25 Nov 2009) introduced
>> suffixcmp() with nearly the same implementation as postfixcmp()
>> that already existed since commit 211c8968 (Make git-remote a
>> builtin, 29 Feb 2008).
> 
> This "nearly the same" piqued my curiosity ;-)

Yeah, I realize I should have explained the differences.
 
> The postfixcmp() you are removing will say "f" > ".txt" while
> suffixcmp() will say "f" < ".txt".
> 
> As postfixcmp() is only used to compare for equality, the
> distinction does not matter and does not affect the correctness of
> this patch, but I am not sure which answer is more correct.

Yeah, that's also my opinion. I am not even sure if there is one more
correct answer than the other.

> I do not think anybody sane uses prefixcmp() or suffixcmp() for
> anything but checking with zero; in other words, I suspect that all
> uses of Xcmp() can be replaced with !!Xcmp(), so as a separate
> clean-up patch, we may at least want to make it clear that the
> callers should not expect anything but "does str have sfx as its
> suffix, yes or no?" by doing something like this:
> 
>  int suffixcmp(const char *str, const char *suffix)
>  {
>  	int len = strlen(str), suflen = strlen(suffix);
>  	if (len < suflen)
>  		return -1;
>  	else
> -		return strcmp(str + len - suflen, suffix);
> +		return !!strcmp(str + len - suflen, suffix);
>  }
> 
> I am not absolutely sure about doing the same to prefixcmp(),
> though. It could be used for ordering, even though no existing code
> seems to do so.

I agree.

I will resend a 2 patch long patch series where the first patch will
have an improved commit message and the second patch will do what you suggest above.

Thanks,
Christian.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
  2013-11-04 19:19 ` Junio C Hamano
  2013-11-04 20:16   ` Christian Couder
@ 2013-11-04 20:21   ` Junio C Hamano
  2013-11-04 22:17     ` Johannes Schindelin
  1 sibling, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2013-11-04 20:21 UTC (permalink / raw)
  To: Christian Couder; +Cc: git, Avery Pennarun, Johannes Schindelin

Junio C Hamano <gitster@pobox.com> writes:

> I do not think anybody sane uses prefixcmp() or suffixcmp() for
> anything but checking with zero; in other words, I suspect that all
> uses of Xcmp() can be replaced with !!Xcmp(), so as a separate
> clean-up patch, we may at least want to make it clear that the
> callers should not expect anything but "does str have sfx as its
> suffix, yes or no?" by doing something like this:
>
>  int suffixcmp(const char *str, const char *suffix)
>  {
>  	int len = strlen(str), suflen = strlen(suffix);
>  	if (len < suflen)
>  		return -1;
>  	else
> -		return strcmp(str + len - suflen, suffix);
> +		return !!strcmp(str + len - suflen, suffix);
>  }
>
> I am not absolutely sure about doing the same to prefixcmp(),
> though. It could be used for ordering, even though no existing code
> seems to do so.

I just realized why this suggestion is incomplete; if we were to go
this route, we should rename the function to has_suffix() or
something. anything-cmp() ought to be usable as an ordering
comparison function, but suffixcmp() clearly isn't.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
  2013-11-04 20:21   ` Junio C Hamano
@ 2013-11-04 22:17     ` Johannes Schindelin
  2013-11-04 22:37       ` Junio C Hamano
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Schindelin @ 2013-11-04 22:17 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Christian Couder, git, Avery Pennarun

Hi Junio,

On Mon, 4 Nov 2013, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I do not think anybody sane uses prefixcmp() or suffixcmp() for
> > anything but checking with zero; in other words, I suspect that all
> > uses of Xcmp() can be replaced with !!Xcmp(), so as a separate
> > clean-up patch, we may at least want to make it clear that the
> > callers should not expect anything but "does str have sfx as its
> > suffix, yes or no?" by doing something like this:
> >
> >  int suffixcmp(const char *str, const char *suffix)
> >  {
> >  	int len = strlen(str), suflen = strlen(suffix);
> >  	if (len < suflen)
> >  		return -1;
> >  	else
> > -		return strcmp(str + len - suflen, suffix);
> > +		return !!strcmp(str + len - suflen, suffix);
> >  }
> >
> > I am not absolutely sure about doing the same to prefixcmp(),
> > though. It could be used for ordering, even though no existing code
> > seems to do so.
> 
> I just realized why this suggestion is incomplete; if we were to go
> this route, we should rename the function to has_suffix() or
> something. anything-cmp() ought to be usable as an ordering
> comparison function, but suffixcmp() clearly isn't.

I have to admit that I do not understand why a change in suffixcmp()'s
behavior is needed.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead
  2013-11-04 22:17     ` Johannes Schindelin
@ 2013-11-04 22:37       ` Junio C Hamano
  0 siblings, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2013-11-04 22:37 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Christian Couder, git, Avery Pennarun

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Mon, 4 Nov 2013, Junio C Hamano wrote:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > I do not think anybody sane uses prefixcmp() or suffixcmp() for
>> > anything but checking with zero; in other words, I suspect that all
>> > uses of Xcmp() can be replaced with !!Xcmp(), so as a separate
>> > clean-up patch, we may at least want to make it clear that the
>> > callers should not expect anything but "does str have sfx as its
>> > suffix, yes or no?" by doing something like this:
>> >
>> >  int suffixcmp(const char *str, const char *suffix)
>> >  {
>> >  	int len = strlen(str), suflen = strlen(suffix);
>> >  	if (len < suflen)
>> >  		return -1;
>> >  	else
>> > -		return strcmp(str + len - suflen, suffix);
>> > +		return !!strcmp(str + len - suflen, suffix);
>> >  }
>> >
>> > I am not absolutely sure about doing the same to prefixcmp(),
>> > though. It could be used for ordering, even though no existing code
>> > seems to do so.
>> 
>> I just realized why this suggestion is incomplete; if we were to go
>> this route, we should rename the function to has_suffix() or
>> something. anything-cmp() ought to be usable as an ordering
>> comparison function, but suffixcmp() clearly isn't.
>
> I have to admit that I do not understand why a change in suffixcmp()'s
> behavior is needed.

I made the suggestion only because I do not understand why the
function should order "f" and ".txt" in the

	"f" < ".txt"

order. Even worse, the other function postfixcmp() orders them the
other way around.

If -1 returned from the function were an indication of error "The
string does not even have that suffix", then I would have been a bit
more sympathetic, and its current behaviour in that case could be
argued as a special case of the broader return value "non-zero (from
the ordinary strcmp() return codeflow) means the string does not
have that suffix and zero means the string ends with the suffix".

But then, a function that pretends to be for ordering comparison,
with a name that ends with cmp(), and then declaring that "no, this
is not for ordering; the sign of the result does not matter--what
only matters is if it returns zero or non-zero", feels quite
schizophrenic, at least to me.

And my earlier suggestion to change the return value *is* not a
right change.  It still keeps the pretense of comparison for
ordering (i.e. ...cmp() name), while returning a value that cannot
possibly be used for ordering.

So I think the right patch should make the function like this:

	int has_suffix(const char *str, const char *suffix)
        {
        	int len = strlen(str);
                int suffix_len = strlen(suffix);
                if (len < suffix_len)
                	return 0;
		return !strcmp(str + len - suffix_len, suffix);
	}

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2013-11-04 22:37 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-03 20:13 [PATCH] builtin/remote: remove postfixcmp() and use suffixcmp() instead Christian Couder
2013-11-04 17:56 ` Jonathan Nieder
2013-11-04 19:19 ` Junio C Hamano
2013-11-04 20:16   ` Christian Couder
2013-11-04 20:21   ` Junio C Hamano
2013-11-04 22:17     ` Johannes Schindelin
2013-11-04 22:37       ` Junio C Hamano

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