[PATCH] fetch-pack: Avoid memcpy() with src==dst

memcpy() may only be used for disjoint memory areas, but when invoked
from cmd_fetch_pack(), we have my_args == &args.  (The argument cannot
be removed entirely because transport.c invokes with its own
variable.)

Signed-off-by: Thomas Rast <redacted>

---

Found this while valgrinding too much.

 builtin-fetch-pack.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 372bfa2..67fb80e 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c

@@ -780,7 +780,8 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
 	struct ref *ref_cpy;
 
 	fetch_pack_setup();
-	memcpy(&args, my_args, sizeof(args));
+	if (&args != my_args)
+		memcpy(&args, my_args, sizeof(args));
 	if (args.depth > 0) {
 		if (stat(git_path("shallow"), &st))
 			st.st_mtime = 0;

-- 
tg: (7f705dc..) t/fp-memcpy-fix (depends on: origin/master)

Thomas Rast [off-list ref] writes:

memcpy() may only be used for disjoint memory areas, but when invoked
from cmd_fetch_pack(), we have my_args == &args.  (The argument cannot
be removed entirely because transport.c invokes with its own
variable.)

It makes me wonder if it might be a better fix to abolish the use of file
scoped global "args" and pass a pointer to "struct fetch_pack_args"
throughout the callchain instead.

In the current code, cmd_fetch_pack() is the only caller that passes &args
to this function, but it is not so implausible to have a future callchain
that makes two calls to cmd_fetch_pack(), perhaps implementing some sort
of alias to fetch from multiple places, would horribly break without such
a fix, because cmd_fetch_pack() assumes that args is in its pristine
state.

I'll apply this to 'maint' and merge it up, because the patch is
independent of the above issue.

Thanks.