🚀 go-pugleaf

Thomas Padron-McCarthy (tompa@ida.liu.se) writes:

> > I wonder: Does the standard guarantee that EXIT_SUCCESS and
> > EXIT_FAILURE are different?

Bill McCarthy (actuary@nando.net) writes:
 
> Not only are they not guaranteed to be different.  EXIT_SUCCESS is
> not guaranteed to be zero, and EXIT_FAILURE is not guaranteed to
> be different from 0.  They are implementation defined and should
> only be used as an argument to exit() or in a return from main().
> 
> They are defined 7.10.4.3 of the standard.

Section 7.10 specifies that

#  ...
#  EXIT_FAILURE
#    and
#  EXIT_SUCCESS
# 
#  ... expand to integral expressions that may be used as argument to
#  the exit function to return successful or unsuccessful termination
#  status, respectively, to the host environment.

The passage in 7.10.4.3 essentially reiterates this with additions:

#  If the value of status is zero or EXIT_SUCCESS, an implementation-
#  "successful termination" is returned.  If the value of status is
#  EXIT_FAILURE, an implementation-defined form of the status
#  "unsuccessful termination" is returned. ...

As "successful termination" and "unsuccessful termination" are in italics
here (rendered as quotes in this ASCII text), they are being defined by
this passage, so they just mean the effects that zero or EXIT_SUCCESS
on the one hand, and EXIT_FAILURE on the other, respectively have.

It seems clear to me that the intent of both passages is to define them
as being distinct statuses, which implies that EXIT_SUCCESS and EXIT_FAILURE
must yield distinct values.  But this is not explicitly stated, and obviously
Bill disagrees.

I might note that it is also not explicit that they should yield *constant*
values.  One can imagine an implementation where EXIT_FAILURE yields one
value if some particular feature was ever used in the program, and another
value if it was not, as a debugging aid.  In that case, if a user function
returns EXIT_FAILURE, comparing the returned value for equality with
EXIT_FAILURE later might not work.  This strikes me as a rather strained
interpretation, though, and I would not object if a ruling prohibited it.
See below. :-)
-- 
Mark Brader           \ "Nitwit ideas are for emergencies.  The rest of the
msb@sq.com             \ time you go by the Book, which is mostly a collection
SoftQuad Inc., Toronto  \ of nitwit ideas that worked.   -- Niven & Pournelle

My text in this article is in the public domain.