Thomas Rast <trast@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
