🚀 go-pugleaf

In <tompa.827763954@news> tompa@ida.liu.se (Thomas Padron-McCarthy) writes:

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

No.  If the host environment doesn't support the concept of termination
status, both macros can legally evaluate to the same value.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In <tompa.827763954@news>, tompa@ida.liu.se (Thomas Padron-McCarthy) writes:
>Hi!
>
>Many of the students in a C course I teach have started to use
>EXIT_SUCCESS and EXIT_FAILURE as return values from functions
>(other than main).
>
>I have never used EXIT_SUCCESS and EXIT_FAILURE for anything
>else than as the return value from main, and as the argument to exit.
>
>I don't like this new practice, but questions of style are difficult.
>So I wonder: Does the standard guarantee that EXIT_SUCCESS and
>EXIT_FAILURE are different?
>
>I have looked in my old ANSI X3-159-1989,
>but I guess I'm not smart enough to understand it...

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.

Bill McCarthy
actuary@nando.net
Wendell, NC  USA

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.

In article <4j7p4p$4n8@castle.nando.net>, actuary@nando.net   (Bill McCarthy) writes:
|> In <tompa.827763954@news>, tompa@ida.liu.se (Thomas Padron-McCarthy) writes:
|> >
|> >Many of the students in a C course I teach have started to use
|> >EXIT_SUCCESS and EXIT_FAILURE as return values from functions
|> >(other than main).
|> >
|> >I don't like this new practice, but questions of style are difficult.
|> >So I wonder: Does the standard guarantee that EXIT_SUCCESS and
|> >EXIT_FAILURE are different?
|> 
|> 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().

This is a little harsh.  While they are not defined to be different,
they will be the same only on a very inferior implementation indeed!
And few students are capable of writing code that can defend itself
against such implementations.

Also, if they use them CONSISTENTLY, it doesn't matter that their
values are not defined.  I would regard this practice as perfectly
reasonable, in context, though I have no intention of adopting it
myself.

To put things in context, do you expect all students to write code
assuming the compilation and execution environments differ in their
character sets and both fixed- and floating-point arithmetic?


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

In article <4jdr0l$ddn@lyra.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick
Maclaren) writes:

    [...]
|> To put things in context, do you expect all students to write code
|> assuming the compilation and execution environments differ in their
|> character sets and both fixed- and floating-point arithmetic?

Yes.  Can you show me an example of good coding practice where this
would make a difference?  (And if your not teaching your students good
coding practice, you shouldn't be teaching them, period.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung

In article <KANZE.96Mar29122705@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes:
|> In article <4jdr0l$ddn@lyra.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick
|> Maclaren) writes:
|> 
|>     [...]
|> |> To put things in context, do you expect all students to write code
|> |> assuming the compilation and execution environments differ in their
|> |> character sets and both fixed- and floating-point arithmetic?
|> 
|> Yes.  Can you show me an example of good coding practice where this
|> would make a difference?  (And if your not teaching your students good
|> coding practice, you shouldn't be teaching them, period.)

Try using complex text handling, manipulating externally-defined
data structures, writing special function libraries or using
radically different systems for the different translation phases.
I agree that these tasks are way beyond the ability of most students
(and even most experienced programmers).

Actually, have you ever pre-processed the code of a compiler on an
ASCII machine for compilation on an EBCDIC one, or vice versa?  I
suspect that you underestimate the difficulties.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679