Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William E. Sommerfeld)
Newsgroups: comp.lang.c
Subject: Re: exit(-1)
Message-ID: <2347@bloom-beacon.MIT.EDU>
Date: 18 Jan 88 21:53:42 GMT
References: <502@cresswell.quintus.UUCP> <6935@brl-smoke.ARPA> <1179@wjvax.UUCP> <1185@wjvax.UUCP> <1225@nmtsun.nmt.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William E. Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 56

In article <1225@nmtsun.nmt.edu> hydrovax@nmtsun.nmt.edu (M. Warner Losh) writes:
>Am I missing something here, or are you saying that because VMS cause
>this so-called mess, that they should have to live with a UNIX like
>kludge, just to make you happy?  When you exit(0) on VMS you get the error
>
>%NONAME-W-NOMESSAGE, No message text for message 0000000
>
>or something similar.  Remember that VMS is not really 'C' based, and
>much of the code is written in a whole slew of languages.  

So what.  You can use exit(), fork(), etc. from BSD UNIX FORTRAN and
Pascal.  

> Would you propose that all of that be rewritten? 

If ANSI doesn't support this, it effectively means that someone will
have to rewrite all the UNIX code which does this to use EXIT_SUCCESS
and EXIT_FAILURE.  VMS is just one machine-dependant, non-portable OS,
whereas UNIX can runs on any hardware that VMS can, and then some.

>The more proper
>VMS implementation of EXIT_STATUS should be SS$_NORMAL, which is
>(at least in 4x) defined to be 1.  Why would you expect an operating
>system dependent scheme such as exit(0) to work on all OS's?  The whole
>world isn't using UNIX.

UNIX is not the only system where zero is success, and non-zero is
failure; for example, Multics `system calls' and library routines
return a status codes which are zero on success, and non-zero on
failure.  Multics is by no means C based, either...  I would say that,
of the systems I have seen, it is far more common to use 0->success,
nonzero->failure.  Besides, on most architectures (except for the
VAX), it's easier to test a whole word against zero than it is to test
the lower bit.  Since you want multiple error values to distinguish
between different cases, and also want to make testing for success as
cheap as possible, this implies that 0 must be success.

It would make a _lot_ of sense if VMS C were to ``go with the flow''
and change exit() so that it actually returned (code ? (code << 1) :
1), assuming that even return codes mark failure, and odd ones mark
success?), or, if that wasn't feasible, (code ? SS$_FAILURE :
SS$_SUCCESS)

An emulation of wait() could perform the reverse transformation for
the benefit of things which wanted to call out to other processes,
assuming that you can emulate the UNIX fork() and wait() calls under
VMS.  

If you wanted to write VMS-specific code, you could use the system
calls directly to talk to other system functions, but then you would
_NOT_ have portable code.  The implementation can define additional
routines (vms_exit(), or whatever) if they wanted to return "success,
sort of" (is that what the other success codes mean?) instead of just
a straight success or failure indication.

				- Bill