Why I won't use ANSI C

[Rahul Dhesi]

In article <7196 at brl-smoke.ARPA> gwyn at 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