From: Junio C Hamano <gitster@pobox•com>
To: Duy Nguyen <pclouds@gmail•com>
Cc: Stefan Beller <sbeller@google•com>,
Git Mailing List <git@vger•kernel.org>
Subject: Re* [PATCH 10/15] commit.c: fix a memory leak
Date: Tue, 24 Mar 2015 14:17:01 -0700 [thread overview]
Message-ID: <xmqq7fu65c4y.fsf_-_@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8A3CptGYNAZ=+k0ykBCp6SGoOLY0nX20WkWQp=qUnxwWg@mail.gmail.com> (Duy Nguyen's message of "Tue, 24 Mar 2015 20:42:17 +0700")
Duy Nguyen <pclouds@gmail•com> writes:
> On Sat, Mar 21, 2015 at 10:59 AM, Junio C Hamano <gitster@pobox•com> wrote:
>> A further tangent (Duy Cc'ed for this point). We might want to
>> rethink the interface to ce_path_match() and report_path_error()
>> so that we do not have to do a separate allocation of "has this
>> pathspec been used?" array. This was a remnant from the olden days
>> back when pathspec were mere "const char **" where we did not have
>> any room to add per-item bit---these days pathspec is repreasented
>> as an array of "struct pathspec" and we can afford to add a bit
>> to the structure---which will make this kind of leak much less
>> likely to happen.
>
> I just want to say "noted" (and therefore in my backlog). But no
> promise that it will happen any time soon. Low hanging fruit, perhaps
> some people may be interested..
OK, the other one I just did so that we won't forget. Otherwise we
will leave too many loose ends untied.
-- >8 --
From: Junio C Hamano <gitster@pobox•com>
Date: Tue, 24 Mar 2015 14:12:10 -0700
Subject: [PATCH] report_path_error(): move to dir.c
The expected call sequence is for the caller to use match_pathspec()
repeatedly on a set of pathspecs, accumulating the "hits" in a
separate array, and then call this function to diagnose a pathspec
that never matched anything, as that can indicate a typo from the
command line, e.g. "git commit Maekfile".
Many builtin commands use this function from builtin/ls-files.c,
which is not a very healthy arrangement. ls-files might have been
the first command to feel the need for such a helper, but the need
is shared by everybody who uses the "match and then report" pattern.
Move it to dir.c where match_pathspec() is defined.
Signed-off-by: Junio C Hamano <gitster@pobox•com>
---
builtin/ls-files.c | 43 -------------------------------------------
cache.h | 1 -
dir.c | 43 +++++++++++++++++++++++++++++++++++++++++++
dir.h | 1 +
4 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 47c3880..47d70b2 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -354,49 +354,6 @@ void overlay_tree_on_cache(const char *tree_name, const char *prefix)
}
}
-int report_path_error(const char *ps_matched,
- const struct pathspec *pathspec,
- const char *prefix)
-{
- /*
- * Make sure all pathspec matched; otherwise it is an error.
- */
- struct strbuf sb = STRBUF_INIT;
- int num, errors = 0;
- for (num = 0; num < pathspec->nr; num++) {
- int other, found_dup;
-
- if (ps_matched[num])
- continue;
- /*
- * The caller might have fed identical pathspec
- * twice. Do not barf on such a mistake.
- * FIXME: parse_pathspec should have eliminated
- * duplicate pathspec.
- */
- for (found_dup = other = 0;
- !found_dup && other < pathspec->nr;
- other++) {
- if (other == num || !ps_matched[other])
- continue;
- if (!strcmp(pathspec->items[other].original,
- pathspec->items[num].original))
- /*
- * Ok, we have a match already.
- */
- found_dup = 1;
- }
- if (found_dup)
- continue;
-
- error("pathspec '%s' did not match any file(s) known to git.",
- pathspec->items[num].original);
- errors++;
- }
- strbuf_release(&sb);
- return errors;
-}
-
static const char * const ls_files_usage[] = {
N_("git ls-files [options] [<file>...]"),
NULL
diff --git a/cache.h b/cache.h
index f23fdbe..8ec0b65 100644
--- a/cache.h
+++ b/cache.h
@@ -1411,7 +1411,6 @@ extern int ws_blank_line(const char *line, int len, unsigned ws_rule);
#define ws_tab_width(rule) ((rule) & WS_TAB_WIDTH_MASK)
/* ls-files */
-int report_path_error(const char *ps_matched, const struct pathspec *pathspec, const char *prefix);
void overlay_tree_on_cache(const char *tree_name, const char *prefix);
char *alias_lookup(const char *alias);
diff --git a/dir.c b/dir.c
index 797805d..5d6e102 100644
--- a/dir.c
+++ b/dir.c
@@ -377,6 +377,49 @@ int match_pathspec(const struct pathspec *ps,
return negative ? 0 : positive;
}
+int report_path_error(const char *ps_matched,
+ const struct pathspec *pathspec,
+ const char *prefix)
+{
+ /*
+ * Make sure all pathspec matched; otherwise it is an error.
+ */
+ struct strbuf sb = STRBUF_INIT;
+ int num, errors = 0;
+ for (num = 0; num < pathspec->nr; num++) {
+ int other, found_dup;
+
+ if (ps_matched[num])
+ continue;
+ /*
+ * The caller might have fed identical pathspec
+ * twice. Do not barf on such a mistake.
+ * FIXME: parse_pathspec should have eliminated
+ * duplicate pathspec.
+ */
+ for (found_dup = other = 0;
+ !found_dup && other < pathspec->nr;
+ other++) {
+ if (other == num || !ps_matched[other])
+ continue;
+ if (!strcmp(pathspec->items[other].original,
+ pathspec->items[num].original))
+ /*
+ * Ok, we have a match already.
+ */
+ found_dup = 1;
+ }
+ if (found_dup)
+ continue;
+
+ error("pathspec '%s' did not match any file(s) known to git.",
+ pathspec->items[num].original);
+ errors++;
+ }
+ strbuf_release(&sb);
+ return errors;
+}
+
/*
* Return the length of the "simple" part of a path match limiter.
*/
diff --git a/dir.h b/dir.h
index 55e5345..ed336ad 100644
--- a/dir.h
+++ b/dir.h
@@ -135,6 +135,7 @@ extern char *common_prefix(const struct pathspec *pathspec);
extern int match_pathspec(const struct pathspec *pathspec,
const char *name, int namelen,
int prefix, char *seen, int is_dir);
+extern int report_path_error(const char *ps_matched, const struct pathspec *pathspec, const char *prefix);
extern int within_depth(const char *name, int namelen, int depth, int max_depth);
extern int fill_directory(struct dir_struct *dir, const struct pathspec *pathspec);
--
2.3.4-449-gebec173
next prev parent reply other threads:[~2015-03-24 21:17 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-21 0:27 [PATCH 00/15] Fixing memory leaks Stefan Beller
2015-03-21 0:27 ` [PATCH 01/15] read-cache: fix memleak Stefan Beller
2015-03-21 3:26 ` Junio C Hamano
2015-03-23 16:24 ` Stefan Beller
2015-03-23 17:57 ` [PATCH 1/2] " Stefan Beller
2015-03-23 17:57 ` [PATCH 2/2] read-cache.c: fix a memleak in add_to_index Stefan Beller
2015-03-23 18:07 ` Junio C Hamano
2015-03-23 18:11 ` [PATCH 1/2] read-cache: fix memleak Junio C Hamano
2015-03-21 0:27 ` [PATCH 02/15] read-cache: Improve readability Stefan Beller
2015-03-21 4:19 ` Junio C Hamano
2015-03-21 5:11 ` Stefan Beller
2015-03-22 19:26 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 03/15] read-cache: free cache entry in add_to_index in case of early return Stefan Beller
2015-03-21 3:31 ` Junio C Hamano
2015-03-21 5:10 ` Stefan Beller
2015-03-22 19:11 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 04/15] update-index: fix a memleak Stefan Beller
2015-03-21 3:40 ` Junio C Hamano
2015-03-23 16:53 ` [PATCH] update-index: Don't copy memory around Stefan Beller
2015-03-23 17:11 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 05/15] builtin/apply.c: fix a memleak Stefan Beller
2015-03-21 3:45 ` Junio C Hamano
2015-03-23 17:13 ` [PATCH] builtin/apply.c: fix a memleak (Fixup, squashable) Stefan Beller
2015-03-23 17:27 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 06/15] merge-blobs.c: Fix a memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 07/15] merge-recursive: fix memleaks Stefan Beller
2015-03-21 3:48 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 08/15] http-push: Remove unneeded cleanup Stefan Beller
2015-03-21 0:28 ` [PATCH 09/15] http: release the memory of a http pack request as well Stefan Beller
2015-03-22 19:36 ` Junio C Hamano
2015-03-24 16:54 ` Stefan Beller
2015-03-24 17:48 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 10/15] commit.c: fix a memory leak Stefan Beller
2015-03-21 3:59 ` Junio C Hamano
2015-03-24 13:42 ` Duy Nguyen
2015-03-24 21:17 ` Junio C Hamano [this message]
2015-03-24 21:20 ` Re* " Stefan Beller
2015-03-21 0:28 ` [PATCH 11/15] builtin/check-attr: fix a memleak Stefan Beller
2015-03-21 4:02 ` Junio C Hamano
2015-03-21 0:28 ` [PATCH 12/15] builtin/merge-base: fix memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 13/15] builtin/unpack-file: fix a memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 14/15] builtin/cat-file: free memleak Stefan Beller
2015-03-21 0:28 ` [PATCH 15/15] ls-files: fix a memleak Stefan Beller
2015-03-21 3:21 ` [PATCH 00/15] Fixing memory leaks Junio C Hamano
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=xmqq7fu65c4y.fsf_-_@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=pclouds@gmail$(echo .)com \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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