Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Tue, 25 Jun 2002 20:35:35 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: some Win32 exit codes become 0 Message-ID: <20020626003535.GH5480@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <2D9D5132D9067C49A484611CD8CE08D469F7A1 AT VELOCE DOT performant DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D9D5132D9067C49A484611CD8CE08D469F7A1@VELOCE.performant.com> User-Agent: Mutt/1.3.23.1i On Tue, Jun 25, 2002 at 03:39:53PM -0700, Ted Romer wrote: >In cygwin-1.3.11-3, if I invoke a Win32 process that exits with >negative status (or status >= 256), cygwin converts the status to 0. > >Good practice or not, programs often use -1 as an exit status >indicating failure, so this makes error checking challenging. > >Easy to reproduce: > >% perl -e 'exit(-1)' % echo $? 0 % jython nosuchscript.py % echo $? 0 > >The cause is that sigproc.cc:stopped_or_terminated assumes that the >EXIT_SIGNAL bit in the exit code in fact indicates that the process >exited due to a signal. This is true for cygwin processes, but not for >Win32 processes. There are some cases where we can't accommodate pure Windows processes. This is one of them. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/