When we try to exec a git sub-command, we pass along the
status code from run_command(). But that may return -1 if we
ran into an error with pipe() or execve(). This tends to
work (and end up as 255 due to twos-complement wraparound
and truncation), but in general it's probably a good idea to
avoid negative exit codes for portability.
We can easily translate to the normal generic "128" code we
get when syscalls cause us to die.
Signed-off-by: Jeff King <p...@peff.net>
---
I know that negative exit codes were a problem once upon a time on
Windows, but I think that is fine since 47e3de0e79 (MinGW: truncate
exit()'s argument to lowest 8 bits, 2009-07-05). Still, I think it's a
weird portability thing that we are better off avoiding (and certainly I
wouldn't be surprised if some callers assume everything >128 is a
signal).
git.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/git.c b/git.c
index d0e04d5c97..bc2f2a7ec9 100644
--- a/git.c
+++ b/git.c
@@ -593,12 +593,16 @@ static void execv_dashed_external(const char **argv)
trace_argv_printf(cmd.args.argv, "trace: exec:");
/*
- * if we fail because the command is not found, it is
- * OK to return. Otherwise, we just pass along the status code.
+ * If we fail because the command is not found, it is
+ * OK to return. Otherwise, we just pass along the status code,
+ * or our usual generic code if we were not even able to exec
+ * the program.
*/
status = run_command(&cmd);
- if (status >= 0 || errno != ENOENT)
+ if (status >= 0)
exit(status);
+ else if (errno != ENOENT)
+ exit(128);
}
static int run_argv(int *argcp, const char ***argv)
--
2.11.0.527.gfef230ca76
