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: Thu, 8 Jul 2004 19:13:35 +0200 (W. Europe Daylight Time) From: Daniel Lungu To: cygwin AT cygwin DOT com Subject: Re: negative error status: gcc vs. cl In-Reply-To: Message-ID: X-X-Sender: lungu AT castor DOT hq DOT k DOT grp MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII :) "The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, [CX] or any :) other value" :) but what you shouldn't do is expect the exit status in the shell to be :) anything other than the least-significant byte of the value you passed: :) "though only the least significant 8 bits (that is, status & 0377) shall :) be available to a waiting parent process." It is exactly what happens when compiling nerr.c with gcc: -----unsigned-8b-exit-status----- % nerr-gcc.exe; echo $? 254 sizeof (int) = 4 [B] on i686 :) So -2 comes back as 254. Sounds like perfectly correct 2's complement :) arithmetic to me! Indeed, but same arithmetic should apply when exit status comes from a "cl compiled .exe". It is not the case when compiling nerr.c with cl: -----wrong-nil(!)-exit-status----- % nerr-cl.exe; echo $? 0 $? cannot distinguish exit(0) from exit(-2) ... this is logical anarchy! One cannot reliably test exit status of legacy windoze binaries. :) cheers, :) DaveK ksh :) yields the same Cygwin bug. Thanks for answers. Daniel. -- 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/