Re: Fix signal handler

From: Jeff King <peff@peff.net>
Date: Feb 3, 2010, 15:17 UTC
Message-ID: <20100203151709.GA28477@coredump.intra.peff.net>
In-Reply-To: <4B696447.10803@web.de>

On Wed, Feb 03, 2010 at 12:55:51PM +0100, Markus Elfring wrote:

Show 9 quoted lines

> > It's not that we're ignoring a specification, it's that there _isn't_
> > a concrete specification for the set of systems we're interested in.
> 
> I have got doubts on your view. Known specifications are available for
> POSIX and corresponding programming languages like C and C++. I know
> that they have got open issues on their own because a few important
> wordings are not as precise and clear as you might prefer.
> 
> For which software environments do you miss programming standards?

Off the top of my head, I have seen mention of git running on Linux, {Free,Net,Open}BSD, Solaris 7-10, OpenSolaris, AIX 5.x and 6.x, HP-UX, Windows, SCO OpenServer, and SCO UnixWare. Not all of those are POSIX, and I am not sure even if they were that we could (or would want to) stick to a strict subset of POSIX. If all of those systems allow less strict behavior, then what is the problem in taking advantage of it if it makes development or maintenance of the code easier?

Ditto for C. We mostly stick to C89, but there are many parts of the C89 standard where behavior may be implementation defined or even undefined, but in practice work just fine. I am not interested in spending a lot of effort working around those issues just to meet the letter of the standard if there is no practical system on which it matters.

> How many efforts would you like to spend on conditional compilation for
> "special" platforms?

If I haven't made that clear, _I_ don't want to spend any effort. If _you_ are concerned about it, feel free to make a patch. If your patch is not too intrusive, and especially if you can demonstrate that it is a problem on a real-world system, then I think your patch would be considered for inclusion upstream.

If you are not willing to spend any effort on these problems, and instead are trying to direct _my_ priorities, then I have no interest in listening to what you have to say (and I suspect that goes for the rest of the regular git developers, too).

-Peff