Path: utzoo!mnetor!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: exit(-1)
Message-ID: <10237@mimsy.UUCP>
Date: 18 Jan 88 21:23:31 GMT
References: <502@cresswell.quintus.UUCP> <6935@brl-smoke.ARPA> <1179@wjvax.UUCP> <1225@nmtsun.nmt.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 45

In article <1225@nmtsun.nmt.edu> hydrovax@nmtsun.nmt.edu (M. Warner
Losh) writes:
>... The more proper VMS implementation of EXIT_STATUS should be
>SS$_NORMAL, which is (at least in 4x) defined to be 1.

(I think it was inherited from RT-11.  It was 1 in VMS 2.8.)

>Why would you expect an operating system dependent scheme such
>as exit(0) to work on all OS's?

Simple.  Let me phrase it this way:  `Why would you expect a standard
library scheme to be dependent on the O/S?'  Or, `whoever said exit
was a system call?'

Unix, by virtue of being the first system to implement the language,
is privileged: it gets to take the argument to exit() and pass it
back to the calling program.  Other systems might have to convert
the argument to 0 => success, anything else => unspecified failure.
(Actually, other systems might attempt to map the exits in
<sysexits.h>.)  This---a boolean success/failure indication---is
as much as, or perhaps even more than, a portable standard could
guarantee.  Specific systems would also provide system specific
versions of exit().  Indeed, Unix systems might define either

	_unix_exit(int status) { exit(status); }

or

	exit(int status) { _unix_exit(status); }

(symmetry means never having to say `oops' :-) )

VMS would provide

	exit(int status) { _vms_exit(_vms_map(status)); }

while AOS/VS would provide

	exit(int stauts) { _aos_exit(_aos_map(status)); }

Of course, this is not what the dpANS says, so the argument is
rather pointless.  But this is what should have been done.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris