Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Jeff King schrieb: >> On Wed, Jul 16, 2008 at 11:31:41PM -0700, Junio C Hamano wrote: >>> Is it that somebody do not want 255 exit value, or anything that has 7th >>> bit set? 2488df8 (builtin run_command: do not exit with -1., 2007-11-13) >>> suggests otherwise at least for Windows runtime, so what we currently have >>> that does extra truncation ourselves might be sufficient. >> >> Johannes will have to answer that; however, the truncation there does >> leave the extra 7th bit. Maybe & 0x7f would be more appropriate? > > I never found out the real reason why -1 would not be recognized as > "failure"; the conclusion of my debugging session was that MSYS bash has > an issue, and I chose to append '& 0xff' because the documentation of > WEXITSTATUS() says that it can receive only 8 bits of the exit() code. The > intention of 2488df8 was to keep as much information as possible. But if > that extra information hurts, we should better truncate to 7 bits. > > The source code of Windows's C runtime suggests that any value that fits > in 4 bytes can be supplied to exit() and can be received by cwait() > (Windows's version of waitpid()); but I haven't looked at how MSYS > implements waitpit() and whether it can receive that much information. Well, POSIX cannot do that much anyway, but does allow 8-bit, so I'd say the current code is fine. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
