diff mbox series

dir: remove unneeded local variables from match_pathname()

Message ID 20230210045119.25190-1-masahiroy@kernel.org (mailing list archive)
State New, archived
Headers show
Series dir: remove unneeded local variables from match_pathname() | expand

Commit Message

Masahiro Yamada Feb. 10, 2023, 4:51 a.m. UTC
The local variables are unneeded - you can simply advance the 'pathname'
pointer.

IMHO, the variable 'name' is somewhat confusing. It is a relative path
to 'base', not a file name. It may contain slashes.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 dir.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

Comments

Junio C Hamano Feb. 10, 2023, 9:51 p.m. UTC | #1
Masahiro Yamada <masahiroy@kernel.org> writes:

> The local variables are unneeded - you can simply advance the 'pathname'
> pointer.

It probably is somewhat subjective if it makes the resulting code
easier or harder to read with these extra variables, even though
"are unneeded" may technically be correct and the compilers may
produce identical binaries with or without the patch.

In the context of the original, this used to be in a loop where
elements of an array was matched against a constant pathname
variable, and it was necessary to use <name, namelen>, separate
variables, to point to the "remainder" of "pathname".  It would not
have made any sense not to use separate variables in that loop.

When the body of the loop was split into this helper function in
b5592632 (exclude: split pathname matching code into a separate
function, 2012-10-15), we could have removed these variables and
instead clobbered <pathname, pathlen>, but apparently we did not.  I
suspect that the original author found it easier to reason about the
behaviour of the function to keep the incoming parameter anchored at
the constant location, and use separate variables to point at the
tail part of the string that are to be worked on, which I tend to
disagree, but I do not have a strong preference.

Having said all that, I consider this to fall into "once the code is
written one way, it is not worth the patch noise to go and change it
to a different way." category.

Thanks.
diff mbox series

Patch

diff --git a/dir.c b/dir.c
index 4e99f0c868..06c6e7d79e 100644
--- a/dir.c
+++ b/dir.c
@@ -1251,9 +1251,6 @@  int match_pathname(const char *pathname, int pathlen,
 		   const char *base, int baselen,
 		   const char *pattern, int prefix, int patternlen)
 {
-	const char *name;
-	int namelen;
-
 	/*
 	 * match with FNM_PATHNAME; the pattern has base implicitly
 	 * in front of it.
@@ -1273,35 +1270,37 @@  int match_pathname(const char *pathname, int pathlen,
 	    fspathncmp(pathname, base, baselen))
 		return 0;
 
-	namelen = baselen ? pathlen - baselen - 1 : pathlen;
-	name = pathname + pathlen - namelen;
+	if (baselen > 0) {
+		pathname += baselen + 1;
+		pathlen -= baselen + 1;
+	}
 
 	if (prefix) {
 		/*
 		 * if the non-wildcard part is longer than the
 		 * remaining pathname, surely it cannot match.
 		 */
-		if (prefix > namelen)
+		if (prefix > pathlen)
 			return 0;
 
-		if (fspathncmp(pattern, name, prefix))
+		if (fspathncmp(pattern, pathname, prefix))
 			return 0;
 		pattern += prefix;
 		patternlen -= prefix;
-		name    += prefix;
-		namelen -= prefix;
+		pathname += prefix;
+		pathlen -= prefix;
 
 		/*
 		 * If the whole pattern did not have a wildcard,
 		 * then our prefix match is all we need; we
 		 * do not need to call fnmatch at all.
 		 */
-		if (!patternlen && !namelen)
+		if (!patternlen && !pathlen)
 			return 1;
 	}
 
 	return fnmatch_icase_mem(pattern, patternlen,
-				 name, namelen,
+				 pathname, pathlen,
 				 WM_PATHNAME) == 0;
 }