Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Thu, 8 Jul 2004 13:13:50 -0400 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: negative error status: gcc vs. cl Message-ID: <20040708171350.GB14402@trixie.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20040708100919.GB32001@cygbert.vinschen.de> <20040708145452.GA14402@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i On Thu, Jul 08, 2004 at 11:23:41AM -0400, Igor Pechtchanski wrote: >On Thu, 8 Jul 2004, Christopher Faylor wrote: > >> On Thu, Jul 08, 2004 at 10:25:09AM -0400, Igor Pechtchanski wrote: >> >On Thu, 8 Jul 2004, Corinna Vinschen wrote: >> > >> >> On Jul 8 11:49, Daniel Lungu wrote: >> >> > Feel like bash tcsh on Cygwin mess up with negative exit status >> >> > from a cl compiled .exe > ^^^^^^^^^^^^^^^^ >> >> The answer is "don't do that". Use positive values in the range from >> >> 0 to 255. See >> >> http://www.opengroup.org/onlinepubs/009695399/functions/exit.html >> > >> >Actually, it looks like another buglet in Cygwin. The code in >> >spawn_guts() in spawn.cc (line 847 in CVS HEAD) simply binary-ORs the >> >exitcode value returned by GetExitCodeProcess with the "res" variable. >> >However, the "res" variable is also used to carry some flags, and a >> >negative exitcode, being a full DWORD, accidentally sets those, so all >> >sorts of havoc can potentially occur (and I'm surprised that all that >> >happens is the wrong exit code). >> >> This is not a bug. A cygwin program can't set a negative exit code. >> Only the lower order 16 bits are used. This is enforced by _exit. >> >> If someone uses ExitProcess in a cygwin program, then well, err... >> cgf > >You would be right if spawn() could only be used for Cygwin programs. It's not spawn*(). It's exec*(). spawn would be unaffected. The effect of a windows program setting a higher order bit would most likely be an eventual system_printf warning from cygwin. >Unfortunately, it can also be used for non-Cygwin programs (as shown by >the underlined phrase above) which don't operate under the above >restriction. So, I'd say that binary-ANDing the exitcode value with 0xFF >(or 0xFFFF if you want 16 bits) is a healthy precaution. It will >certainly do no harm, and it will make absolutely sure that the other >flags (e.g., EXIT_REPARENTING) are never tread upon. I wouldn't make a change like that without inspecting the impact of how this affects EXIT_SIGNAL. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/