When getting the result of remote_ls(), we were advancing the variable
"path" to the relative path inside the repository.
However, then we went on to malloc a bogus amount of memory: we were
subtracting the prefix length _again_, quite possibly getting something
negative, which xmalloc() interprets as really, really much.
Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
---
Note that the push in t5540 is still broken, as http-push does
not handle packed-refs (when looking what branches are on the
remote side).
It should not even try to access the directory structure under
refs/ to begin with, but read info/refs instead.
However, that is just one example of the ugliness that is
http-push.c; it also seems to be a perfect example of a copy-pasting
hell; just look at the output of "git grep
curl_easy_setopt http-push.c".
There _has_ to be lot of room for improvement.
http-push.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/http-push.c b/http-push.c
index 9fcccee..cb5bf95 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1435,10 +1435,8 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
}
if (path) {
path += remote->path_len;
+ ls->dentry_name = xstrdup(path);
}
- ls->dentry_name = xmalloc(strlen(path) -
- remote->path_len + 1);
- strcpy(ls->dentry_name, path + remote->path_len);
} else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
ls->dentry_flags |= IS_DIR;
}
@@ -1449,6 +1447,12 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
}
}
+/*
+ * NEEDSWORK: remote_ls() ignores info/refs on the remote side. But it
+ * should _only_ heed the information from that file, instead of trying to
+ * determine the refs from the remote file system (badly: it does not even
+ * know about packed-refs).
+ */
static void remote_ls(const char *path, int flags,
void (*userFunc)(struct remote_ls_ctx *ls),
void *userData)
--
1.6.1.325.g062d4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
