Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: Why I won't use ANSI C
Message-ID: <1992@bsu-cs.UUCP>
Date: 30 Jan 88 04:07:39 GMT
References: <7170@brl-smoke.ARPA> <7183@brl-smoke.ARPA> <1962@bsu-cs.UUCP> <7196@brl-smoke.ARPA>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 27
Summary: I WILL use ANSI C, but read on

In article <7196@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 
writes:
>There has always been a need for a well-defined
>failure status code, or do we insist that all non-zero values indicate
>failure?  (They don't on UNIX; it's the value modulo 256.)

I hear what Doug says.  I think we ought to at least insist that a
small positive value (e.g. 1..maximum value of unsigned char) represent
failure.  I'm alarmed that an implementation that treats exit(1) or
exit(2) (or BOTH) as a successsful status can be ANSI-conformant.  It's
simply too great a departure from established practice.  Probably 98%
of all existing C programs--rough guess--do exit(1) or exit(2) on a
serious error.  I just don't see how the trivial benefit of avoiding
a one-line encapsulation

     exit(i) int i; { _vms_exit (i ? SYS$_FAILURE : SYS$_NORMAL); }

justifies the lack of upward compatibility.  ANSI could simply
"deprecate" the use of arbitrary positive values in preparation for a
complete switch to just two exit symbols in a future revision of the
standard.

The above should not be taken as criticism of ANSI or Doug Gwyn in
general.  I'm sure he is a valuable asset to the standardization
effort, and he's definitely a valuable link between ANSI and the net.
It *should* be taken as criticism of this particular decision.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi