Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!aurora!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: exit(-1)
Message-ID: <10089@mimsy.UUCP>
Date: 8 Jan 88 02:19:06 GMT
References: <502@cresswell.quintus.UUCP> <6935@brl-smoke.ARPA> <1179@wjvax.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 33

>>VMS C would like for exit(1); to also mean "success", we were told,

In article <1179@wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes:
>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?

This is not the right approach.  The right approach is this:

	exit(int status) { _vms_exit(!status); }
		/* more complex encodings can be devised */
		/* note that _vms_exit shuts down stdio in this example */
	_exit(int status) { _vms_stopcold(!status); }
		/* just another example */

The `problem' is that VMS programmers need access to the full range
of VMS status values.  There are many sub-fields to a VMS status.
The low bit means `success'; the next few bits define what sort of
error; a few more define a sub-error or previous error or something
similar; and so forth.  (Incidentally, exit status 0 in VMS means
`failed, no errors occurred'.  It is also possible to exit with
`succeeded, but fatal errors occurred'.)

But VMS status values mean nothing on other operating systems!
Writing

	exit(0x1074);	/* some fancy error or another */

means nothing outside of VMS---so why not use a VMS-specific function
such as _vms_exit()?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris