Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!tank!mimsy!eneevax!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: exit codes (was: Identifier length?)
Message-ID: <9902@smoke.BRL.MIL>
Date: 22 Mar 89 06:22:45 GMT
References: <627@maxim.ERBE.SE> <1989Mar16.171213.21210@utzoo.uucp> <6161@bsu-cs.UUCP> <1989Mar17.175939.1226@utzoo.uucp> <6212@bsu-cs.UUCP> <12111@haddock.ima.isc.com> <6268@bsu-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <6268@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>Existing programs almost never use anything other than a return code of
>0, 1, or 2.  It almost doesn't matter what the standard says about the
>number of bits used.  In fact the standard could simply have said:
>"...if the value of the exit code is not 0, 1, or 2, it is interpreted
>in an implementation-dependent manner".  That would not affect more
>than about 0.2% of existing C programs.  The current standard affects
>all of them.

Not true.  Existing UNIX C programs that use exit codes as you describe
will continue to work when the UNIX environment is upgraded to ANSI C
standard conformance.  Existing C programs that rely on UNIX semantics
for the exit codes are already nonportable, and the C standard reflects
that fact (it doesn't *cause* it).  After a long pitched battle, X3J11
at least agreed that 0 could be promised to mean "success" in all
conforming implementations.  Thus, if you don't want to use the
portability macros EXIT_SUCCESS and EXIT_FAILURE, so long as your
application is always "successful" even in adverse circumstances you
can have it terminate by returning 0 in any conforming hosted environment.