Jeff King <peff@xxxxxxxx> writes:
>> > + prune_object(path->buf, sha1);
>> > + path->len = baselen;
>>
>> This is minor, but I prefer using strbuf_setlen() for this.
>
> Good catch. I do not think it is minor at all; my version is buggy.
> After the loop ends, path->len does not match the NUL in path->buf. That
> is OK if the next caller is strbuf-aware, but if it were to pass
> path->buf straight to a system call, that would be rather...confusing.
Hmph, rmdir(path->buf) at the end of prune_dir() may have that exact
issue.
Will squash in the following.
builtin/prune.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index 4ca8ec1..99f3f35 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -17,7 +17,7 @@ static int verbose;
static unsigned long expire;
static int show_progress = -1;
-static int prune_tmp_object(const char *fullpath)
+static int prune_tmp_file(const char *fullpath)
{
struct stat st;
if (lstat(fullpath, &st))
@@ -78,13 +78,13 @@ static int prune_dir(int i, struct strbuf *path)
strbuf_addf(path, "/%s", de->d_name);
prune_object(path->buf, sha1);
- path->len = baselen;
+ strbuf_setlen(&path, baselen);
continue;
}
if (!prefixcmp(de->d_name, "tmp_obj_")) {
strbuf_addf(path, "/%s", de->d_name);
- prune_tmp_object(path->buf);
- path->len = baselen;
+ prune_tmp_file(path->buf);
+ strbuf_setlen(&path, baselen);
continue;
}
fprintf(stderr, "bad sha1 file: %s/%s\n", path->buf, de->d_name);
@@ -108,7 +108,7 @@ static void prune_object_dir(const char *path)
for (i = 0; i < 256; i++) {
strbuf_addf(&buf, "%02x", i);
prune_dir(i, &buf);
- buf.len = baselen;
+ strbuf_setlen(&buf, baselen);
}
}
@@ -130,7 +130,7 @@ static void remove_temporary_files(const char *path)
}
while ((de = readdir(dir)) != NULL)
if (!prefixcmp(de->d_name, "tmp_"))
- prune_tmp_object(mkpath("%s/%s", path, de->d_name));
+ prune_tmp_file(mkpath("%s/%s", path, de->d_name));
closedir(dir);
}
--
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