summaryrefslogtreecommitdiff
path: root/pathspec.h
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-03-20 21:28:49 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-03-21 11:18:41 -0700
commite4da43b1f063d227b5f7d2922d27458748763a2d (patch)
tree3631b191d2bbd3f7cbc6e98188d65b0fe7c1974a /pathspec.h
parentprefix_filename: drop length parameter (diff)
downloadtgif-e4da43b1f063d227b5f7d2922d27458748763a2d.tar.xz
prefix_filename: return newly allocated string
The prefix_filename() function returns a pointer to static storage, which makes it easy to use dangerously. We already fixed one buggy caller in hash-object recently, and the calls in apply.c are suspicious (I didn't dig in enough to confirm that there is a bug, but we call the function once in apply_all_patches() and then again indirectly from parse_chunk()). Let's make it harder to get wrong by allocating the return value. For simplicity, we'll do this even when the prefix is empty (and we could just return the original file pointer). That will cause us to allocate sometimes when we wouldn't otherwise need to, but this function isn't called in performance critical code-paths (and it already _might_ allocate on any given call, so a caller that cares about performance is questionable anyway). The downside is that the callers need to remember to free() the result to avoid leaking. Most of them already used xstrdup() on the result, so we know they are OK. The remainder have been converted to use free() as appropriate. I considered retaining a prefix_filename_unsafe() for cases where we know the static lifetime is OK (and handling the cleanup is awkward). This is only a handful of cases, though, and it's not worth the mental energy in worrying about whether the "unsafe" variant is OK to use in any situation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pathspec.h')
0 files changed, 0 insertions, 0 deletions