Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: exit(-1)
Message-ID: <6983@brl-smoke.ARPA>
Date: 8 Jan 88 05:37:45 GMT
References: <502@cresswell.quintus.UUCP> <6935@brl-smoke.ARPA> <1179@wjvax.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 31

In article <1179@wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes:
>It appears to me that requiring EXIT_FAILURE and EXIT_SUCCESS is a
>sop to VMS's non-traditional usage.

Yes, it was, but the argument was made that the exit status is intended
to pass system-specific useful information back to the environment, and
I have a hard time arguing against that because UNIX does that all the
time.  Clearly, X3J11 is in no position to dictate what various system
information must consist of, other than "generic success" and "generic
failure" which are the only useful statuses for portable applications.

>However, it is hard to conceive an implementation
>which has multiple exit-success values.

VMS does!

I agree that probably all implementations, including VMS, will
	#define	EXIT_SUCCESS	0

>Instead of accommodating VMS's stupid choice of exit values, why not require
>an ANSI-conforming VMS C compiler to swap 0 and 1 in the exit() in its C
>library?

We tried that, but many existing VMS applications have been passing
the value of 1 (disguised as SYS$SUCCESS or something like that) to
exit() to indicate success.

>This is apt, since VMS caused the problem in the first place.

Actually, I agree with this, but since we found a solution that the
VMS folk could live with, why not stick with it.