Re: [PATCH v3 2/2] git_path(): handle `.lock` files correctly
From: SZEDER Gábor <hidden>
Date: 2019-10-28 12:32:20
On Mon, Oct 28, 2019 at 01:01:49PM +0100, Johannes Schindelin wrote:
quoted
quoted
@@ -349,10 +349,16 @@ static int check_common(const char *unmatched, void *value, void *baton) static void update_common_dir(struct strbuf *buf, int git_dir_len, const char *common_dir) { - char *base = buf->buf + git_dir_len; + char *base = buf->buf + git_dir_len, *base2 = NULL; + + if (ends_with(base, ".lock")) + base = base2 = xstrndup(base, strlen(base) - 5);Hm, this adds the magic number 5 and calls strlen(base) twice, because ends_with() calls strip_suffix(), which calls strlen(). Calling strip_suffix() directly would allow us to avoid the magic number and the second strlen(): size_t len; if (strip_suffix(base, ".lock", &len)) base = base2 = xstrndup(base, len);Actually, we should probably avoid the extra allocation. Earlier, I was concerned about multi-threading issues when attempting to modify the `strbuf`. But then, we modify that `strbuf` a couple of lines later anyway,
Do we? You're right, we do indeed, because in replace_dir(buf, ...) we call strbuf_splice(buf, ...). OK, then your suggestion below is even better.
so my fears were totally unfounded. Therefore, my current version reads like this: -- snip -- int has_lock_suffix = strbuf_strip_suffix(buf, LOCK_SUFFIX); init_common_trie(); if (trie_find(&common_trie, base, check_common, NULL) > 0) replace_dir(buf, git_dir_len, common_dir); if (has_lock_suffix) strbuf_addstr(buf, LOCK_SUFFIX); -- snap --