Re: [PATCH 1/4] tests: factor portable signal check out of t0005

On Fri, Jun 24, 2016 at 10:52:32PM +0200, Johannes Sixt wrote:

Am 24.06.2016 um 21:43 schrieb Jeff King:

quoted

In POSIX shells, a program which exits due to a signal
generally has an exit code of 128 plus the signal number.
However, some platforms do other things. ksh uses 256 plus
the signal number, and on Windows, all signals are just "3".

That's not true, see below.

I was worried about that. Git for Windows seems like a labyrinth of
bizarre special cases.

quoted

I didn't get into the weirdness of SIGPIPE on Windows here, but I think
this is probably a first step toward handling it better. E.g., it may be
that test_match_signal should respect 128 (or even any code) when we are
checking for SIGPIPE.

The Windows behavior is most closely described as having signal(SIGPIPE,
SIG_IGN) at the very beginning of the program.

Right, but then we would get EPIPE. So what does git do in such cases?
I'd expect it generally to either hit the check_pipe() part of
write_or_die(), or to end up complaining via die() that the write didn't
go as expected.

quoted

+# Returns true if the numeric exit code in "$2" represents the expected signal
+# in "$1". Signals should be given numerically.
+test_match_signal () {
+	if test "$2" = "$((128 + $1))"
+	then
+		# POSIX
+		return 0
+	elif test "$2" = "$((256 + $1))"
+	then
+		# ksh
+		return 0
+	elif test "$2" = "3"; then
+		# Windows

You meant well here, but this is close to pointless as a general check. We
check for this exit code in t0005 because there program termination happens
via raise(), which on Window just calls exit(3). This exit code is not an
indication that something related to SIGPIPE (or any signal) happened.

IMO there is too much danger to trigger a false positive if exit code 3 is
treated special in this generality.

Yeah, I agree. But what _should_ it do? E.g., what happens to git-daemon
when it is killed via TERM?

-Peff