From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: Funny: git -p submodule summary Date: Mon, 12 Jan 2009 07:03:45 -0500 Message-ID: <20090112120345.GA12087@coredump.intra.peff.net> References: <20090109083836.GB21389@coredump.intra.peff.net> <20090109092250.GA1809@coredump.intra.peff.net> <49672244.80200@viscovery.net> <20090109101335.GA4346@coredump.intra.peff.net> <496728B9.7090200@viscovery.net> <20090111112222.GA29656@coredump.intra.peff.net> <496B2278.9050905@viscovery.net> <20090112112109.GA3825@coredump.intra.peff.net> <496B30C5.2060207@viscovery.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Junio C Hamano , Johannes Schindelin , git@vger.kernel.org To: Johannes Sixt X-From: git-owner@vger.kernel.org Mon Jan 12 13:06:02 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1LMLYH-0002D0-Bl for gcvg-git-2@gmane.org; Mon, 12 Jan 2009 13:05:54 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753056AbZALMDt (ORCPT ); Mon, 12 Jan 2009 07:03:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752187AbZALMDs (ORCPT ); Mon, 12 Jan 2009 07:03:48 -0500 Received: from peff.net ([208.65.91.99]:46751 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105AbZALMDs (ORCPT ); Mon, 12 Jan 2009 07:03:48 -0500 Received: (qmail 32762 invoked by uid 107); 12 Jan 2009 12:03:48 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.40) with (AES128-SHA encrypted) SMTP; Mon, 12 Jan 2009 07:03:48 -0500 Received: by coredump.intra.peff.net (sSMTP sendmail emulation); Mon, 12 Jan 2009 07:03:45 -0500 Content-Disposition: inline In-Reply-To: <496B30C5.2060207@viscovery.net> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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? > > 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