Re: Funny: git -p submodule summary

From: Jeff King <peff@peff.net>
Date: Jan 12, 2009, 12:03 UTC
Message-ID: <20090112120345.GA12087@coredump.intra.peff.net>
In-Reply-To: <496B30C5.2060207@viscovery.net>

On Mon, Jan 12, 2009 at 01:00:05PM +0100, Johannes Sixt wrote:

> Good question. The exit code is 0xc000013a if the signal was generated by
> hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
> signal was "generated" by 'raise(SIGINT)'. The implementation of the
> latter just calls _exit(3) (same for other deadly signals). Wow!

Eh? So it doesn't even run the signal handlers? Or if it is SIG_DFL (i.e., we have already run all the handlers), then it just calls _exit?

Show 6 quoted lines

> > Don't these get fed to signal()? Does Windows really not care about
> > getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
> > are we just ignoring the return code everywhere?
> 
> Windows's signal() does return EINVAL; appearently, we never check the
> return code. :-P

OK. That makes sense; we don't bother checking the return code because it's mostly just registering a cleanup function. The only sane thing to do on an error (besides ignore it) is to abort whatever we're doing, and I'm not sure it's worth it.

I do feel a little like this is a trap waiting to spring for future coders to break Windows, but I think your change doesn't make anything _worse_ in that regard.

-Peff