user/sven/git.git/run-command.c, branch v1.6.5.4

Test for WIN32 instead of __MINGW32_

2009-09-19T03:00:42Z

The code which is conditional on MinGW32 is actually conditional on Windows. Use the WIN32 symbol, which is defined by the MINGW32 and MSVC environments, but not by Cygwin. Define SNPRINTF_SIZE_CORR=1 for MSVC too, as its vsnprintf function does not add NUL at the end of the buffer if the result fits the buffer size exactly. Signed-off-by: Frank Li Signed-off-by: Marius Storm-Olsen Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Fix __stdcall placement and function prototype

2009-09-19T03:00:42Z

MSVC requires __stdcall to be between the functions return value and the function name, and that the function pointer type is in the form of return_type (WINAPI *function_name)(arguments...) Signed-off-by: Frank Li Signed-off-by: Marius Storm-Olsen Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Avoid declaration after statement

2009-09-19T03:00:41Z

MSVC does not understand this C99 style. Signed-off-by: Frank Li Signed-off-by: Marius Storm-Olsen Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

start_command: do not clobber cmd->env on Windows code path

2009-09-11T23:33:54Z

Previously, it would not be possible to call start_command twice for the same struct child_process that has env set. The fix is achieved by moving the loop that modifies the environment block into a helper function. This also allows us to make two other helper functions static. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'js/run-command-updates'

2009-08-11T05:14:57Z

* js/run-command-updates: api-run-command.txt: describe error behavior of run_command functions run-command.c: squelch a "use before assignment" warning receive-pack: remove unnecessary run_status report run_command: report failure to execute the program, but optionally don't run_command: encode deadly signal number in the return value run_command: report system call errors instead of returning error codes run_command: return exit code as positive value MinGW: simplify waitpid() emulation macros

run-command.c: squelch a "use before assignment" warning

2009-08-04T17:04:29Z

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) compiler (and probably others) mistakenly thinks variable failed_errno is used before assigned. Work it around by giving it a fake initialization. Signed-off-by: David Soria Parra Signed-off-by: Junio C Hamano

run_command: report failure to execute the program, but optionally don't

2009-07-06T09:45:50Z

In the case where a program was not found, it was still the task of the caller to report an error to the user. Usually, this is an interesting case but only few callers actually reported a specific error (though many call sites report a generic error message regardless of the cause). With this change the error is reported by run_command, but since there is one call site in git.c that does not want that, an option is added to struct child_process, which is used to turn the error off. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

run_command: encode deadly signal number in the return value

2009-07-06T09:44:56Z

We now write the signal number in the error message if the program terminated by a signal. The negative return value is constructed such that after truncation to 8 bits it looks like a POSIX shell's $?: $ echo 0000 | { git upload-pack .; echo $? >&2; } | : error: git-upload-pack died of signal 13 141 Previously, the exit code was 255 instead of 141. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

run_command: report system call errors instead of returning error codes

2009-07-06T09:44:49Z

The motivation for this change is that system call failures are serious errors that should be reported to the user, but only few callers took the burden to decode the error codes that the functions returned into error messages. If at all, then only an unspecific error message was given. A prominent example is this: $ git upload-pack . | : fatal: unable to run 'git-upload-pack' In this example, git-upload-pack, the external command invoked through the git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to report the real cause. In fact, this very error message is copied to the syslog if git-daemon's client aborts the connection early. With this change, system call failures are reported immediately after the failure and only a generic failure code is returned to the caller. In the above example the error is now to the point: $ git upload-pack . | : error: git-upload-pack died of signal Note that there is no error report if the invoked program terminated with a non-zero exit code, because it is reasonable to expect that the invoked program has already reported an error. (But many run_command call sites nevertheless write a generic error message.) There was one special return code that was used to identify the case where run_command failed because the requested program could not be exec'd. This special case is now treated like a system call failure with errno set to ENOENT. No error is reported in this case, because the call site in git.c expects this as a normal result. Therefore, the callers that carefully decoded the return value still check for this condition. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

run_command: return exit code as positive value

2009-07-05T19:16:27Z

As a general guideline, functions in git's code return zero to indicate success and negative values to indicate failure. The run_command family of functions followed this guideline. But there are actually two different kinds of failure: - failures of system calls; - non-zero exit code of the program that was run. Usually, a non-zero exit code of the program is a failure and means a failure to the caller. Except that sometimes it does not. For example, the exit code of merge programs (e.g. external merge drivers) conveys information about how the merge failed, and not all exit calls are actually failures. Furthermore, the return value of run_command is sometimes used as exit code by the caller. This change arranges that the exit code of the program is returned as a positive value, which can now be regarded as the "result" of the function. System call failures continue to be reported as negative values. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano