Re: [PATCH] t0005: skip signal death exit code test on Windows

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:
>
>> > Thanks. I wasn't quite clear on how the signal handling worked on
>> > Windows, but from your description, I agree there is not any point in
>> > running the test at all.
>> 
>> Shouldn't we clarify that Git exit codes only work on UNIX-like
>> operating systems?
>
> Clarify where? My impression is that this issue is well-known in the
> msys world, and it is a platform issue, not a git issue.

I actually was scratching my head while reading "the implementation
of raise() just calls exit(3)." part, in this:

> The particular deficiency is that when a signal is raise()d whose SIG_DFL
> action will cause process death (SIGTERM in this case), the
> implementation of raise() just calls exit(3).

After a bit of web searching, it seems to me that this behaviour of
raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls
that.  In other words, "the implementation of raise()" is at an even
lower level than mingw/msys, and I would agree that it is a platform
issue.

> If somebody wants to write a note somewhere in the git
> documentation, that's fine with me, but I'm not clear on exactly
> what it would even say.

I agree with both points.  I can suggest to clarify the log message
a bit with "the implementation of raise() in msvcrt (Microsoft C
Runtime library) just calls exit(3)", but that does not address the
end-user documentation issue.

I tried to summarize the issue for end-user documentation and came
up with this:

    The Git implementation on MinGW exits with status code 3 upon
    receiving an uncaught process-terminating signal, just like any
    program that link with msvcrt (Microsoft C Runtime library)
    whose raise() implementation just calls exit(3).  This is
    different from Git on POSIX, which reports a death by receiving
    a signal with the exit status code (128 + signal number).

But when stated this way, it feels that it belongs to Msysgit
documentation, not ours, at least to me.