diff options
author | Jeff King <peff@peff.net> | 2017-03-20 21:28:49 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-03-21 11:18:41 -0700 |
commit | e4da43b1f063d227b5f7d2922d27458748763a2d (patch) | |
tree | 3631b191d2bbd3f7cbc6e98188d65b0fe7c1974a /pathspec.h | |
parent | prefix_filename: drop length parameter (diff) | |
download | tgif-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