git/exec_cmd.c, branch main

exec_cmd: rename to use dash in file name

2018-04-11T09:11:00Z

This is more consistent with the project style. The majority of Git's source files use dashes in preference to underscores in their file names. Signed-off-by: Stefan Beller

git_extract_argv0_path: do nothing without RUNTIME_PREFIX

2017-09-07T00:41:14Z

When the RUNTIME_PREFIX compile-time knob isn't set, we never look at the argv0_path we extract. We can push its declaration inside the #ifdef to make it more clear that the extract code is effectively a noop. This also un-confuses leak-checking of the argv0_path variable when RUNTIME_PREFIX isn't set. The compiler is free to drop this static variable that we set but never look at (and "gcc -O2" does so). But the compiler still must call strbuf_detach(), since it doesn't know whether that function has side effects; it just throws away the result rather than putting it into the global. Leak-checkers which work by scanning the data segment for pointers to heap blocks would normally consider the block as reachable at program end. But if the compiler removes the variable entirely, there's nothing to find. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

system_path: move RUNTIME_PREFIX to a sub-function

2017-09-07T00:41:11Z

The system_path() function has an #ifdef in the middle of it. Let's move the conditional logic into a sub-function. This isolates it more, which will make it easier to change and add to. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'js/exec-path-coverity-workaround'

2017-01-31T21:14:57Z

Code cleanup. * js/exec-path-coverity-workaround: git_exec_path: do not return the result of getenv() git_exec_path: avoid Coverity warning about unfree()d result

git_exec_path: do not return the result of getenv()

2017-01-09T09:29:50Z

The result of getenv() is not guaranteed by POSIX to last beyond another call to getenv(), or setenv(), etc. We should duplicate the string before returning to the caller to avoid any surprises. We already keep a cached pointer to avoid repeatedly leaking the result of system_path(). We can use the same pointer here to avoid allocating and leaking for each call. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

git_exec_path: avoid Coverity warning about unfree()d result

2017-01-09T01:21:32Z

Technically, it is correct that git_exec_path() returns a possibly malloc()ed string returned from system_path(), and it is sometimes not allocated. Cache the result in a static variable and make sure that we call system_path() only once, which plugs a potential leak. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

common-main: stop munging argv[0] path

2016-11-29T19:01:48Z

Since 650c44925 (common-main: call git_extract_argv0_path(), 2016-07-01), the argv[0] that is seen in cmd_main() of individual programs is always the basename of the executable, as common-main strips off the full path. This can produce confusing results for git-daemon, which wants to re-exec itself. For instance, if the program was originally run as "/usr/lib/git/git-daemon", it will try just re-execing "git-daemon", which will find the first instance in $PATH. If git's exec-path has not been prepended to $PATH, we may find the git-daemon from a different version (or no git-daemon at all). Normally this isn't a problem. Git commands are run as "git daemon", the git wrapper puts the exec-path at the front of $PATH, and argv[0] is already "daemon" anyway. But running git-daemon via its full exec-path, while not really a recommended method, did work prior to 650c44925. Let's make it work again. The real goal of 650c44925 was not to munge argv[0], but to reliably set the argv0_path global. The only reason it munges at all is that one caller, the git.c wrapper, piggy-backed on that computation to find the command basename. Instead, let's leave argv[0] untouched in common-main, and have git.c do its own basename computation. While we're at it, let's drop the return value from git_extract_argv0_path(). It was only ever used in this one callsite, and its dual purposes is what led to this confusion in the first place. Note that by changing the interface, the compiler can confirm for us that there are no other callers storing the return value. But the compiler can't tell us whether any of the cmd_main() functions (besides git.c) were relying on the basename munging. However, we can observe that prior to 650c44925, no other cmd_main() functions did that munging, and no new cmd_main() functions have been introduced since then. So we can't be regressing any of those cases. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/tighten-alloc'

2016-02-26T21:37:16Z

Update various codepaths to avoid manually-counted malloc(). * jk/tighten-alloc: (22 commits) ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation ...

prepare_{git,shell}_cmd: use argv_array

2016-02-22T22:51:09Z

These functions transform an existing argv into one suitable for exec-ing or spawning via git or a shell. We can use an argv_array in each to avoid dealing with manual counting and allocation. This also makes the memory allocation more clear and fixes some leaks. In prepare_shell_cmd, we would sometimes allocate a new string with "$@" in it and sometimes not, meaning the caller could not correctly free it. On the non-Windows side, we are in a child process which will exec() or exit() immediately, so the leak isn't a big deal. On Windows, though, we use spawn() from the parent process, and leak a string for each shell command we run. On top of that, the Windows code did not free the allocated argv array at all (but does for the prepare_git_cmd case!). By switching both of these functions to write into an argv_array, we can consistently free the result as appropriate. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

exec_cmd.c: use find_last_dir_sep() for code simplification

2016-02-19T21:26:38Z

We are trying to extract dirname from argv0 in the git_extract_argv0_path(). But in the same time, the provides find_last_dir_sep() to get dirname from a given path. Let's use it instead of loop for the code simplification. Signed-off-by: Alexander Kuleshov Signed-off-by: Junio C Hamano