Thread (14 messages) flat view 14 messages, 3 authors, 2016-06-15

Re: [PATCH 3/3] clean: improve performance when removing lots of directories

From: Eric Sunshine <hidden>
Date: 2016-06-15 23:04:24

On Tue, Apr 7, 2015 at 3:55 PM, erik elfström [off-list ref] wrote:
On Tue, Apr 7, 2015 at 12:10 AM, Eric Sunshine [off-list ref] wrote:
quoted
On Mon, Apr 6, 2015 at 7:48 AM, Erik Elfström [off-list ref] wrote:
quoted
diff --git a/builtin/clean.c b/builtin/clean.c
index 98c103f..e951bd9 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
+static int is_git_repository(struct strbuf *path)
+{
+       int ret = 0;
+       if (is_git_directory(path->buf))
+               ret = 1;
+       else {
+               int orig_path_len = path->len;
+               if (path->buf[orig_path_len - 1] != '/')
Minor: I don't know how others feel about it, but I always find it a
bit disturbing to see a potential negative array access without a
safety check that orig_path_len is not 0, either directly in the
conditional or as a documenting assert().
I think I would prefer to accept empty input and return false rather
than assert. What to you think about:

static int is_git_repository(struct strbuf *path)
{
    int ret = 0;
    size_t orig_path_len = path->len;
    if (orig_path_len == 0)
        ret = 0;
My concern in raising the issue is that someone reviewing the patch or
reading the code later won't necessarily know whether you took the
potential negative array access into account and dismissed it as
"can't happen", or if you overlooked the possibility altogether. Had
there been an explicit check in the code (either assert() or other
special handling such as returning 'false'), a comment in the code, or
mention in the commit message, then it would have been clear that you
took the case into consideration, and I wouldn't have worried about
it.

As for the this proposed version of is_git_repository(), I don't have
strong feelings, and can formulate arguments either way. If it doesn't
make sense for is_git_repository() ever to be called with empty input,
then assert() may be the better choice for documenting that fact.
However, if you foresee some need for allowing empty input, or if you
audited the functionality and found that it can already be called with
empty input, then returning 'false' makes sense. Use your best
judgment.
quoted hunk ↗ jump to hunk
    else if (is_git_directory(path->buf))
        ret = 1;
    else {
        if (path->buf[orig_path_len - 1] != '/')
            strbuf_addch(path, '/');
        strbuf_addstr(path, ".git");
        if (is_git_directory(path->buf))
            ret = 1;
        strbuf_setlen(path, orig_path_len);
    }

    return ret;
}


Also I borrowed this pattern from remove_dirs and it has the same
problem. Should I add something like this as a separate commit?
diff --git a/builtin/clean.c b/builtin/clean.c
index ccffd8a..88850e3 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -201,6 +202,7 @@ static int remove_dirs(struct strbuf *path, const
char *prefix, int force_flag,
                return res;
        }

+       assert(original_len > 0 && "expects non-empty path");
        if (path->buf[original_len - 1] != '/')
                strbuf_addch(path, '/');
I personally wouldn't mind such a patch. (I'm not sure that the string
within the assert() adds much value, and it's a not-much-used idiom
within the Git source.)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help