EXIT_SUCCESS guaranteed to always be zero?

[Mantorok Redgormor]

Finally, control is returned to the host environment. If the value of
status is zero or EXIT_SUCCESS, an implementation-defined form of the
status successful termination is returned.

beyond this paragraph from the standard, I can't determine if this
macro
will always be zero. It would surely be convenient if it is but it
never
states this directly. the "zero or" part, leads me to believe that the
macro
can be something other than zero, but I'm not too sure.

 

[Alex]

Finally, control is returned to the host environment. If the value of
status is zero or EXIT_SUCCESS, an implementation-defined form of the
status successful termination is returned.

beyond this paragraph from the standard, I can't determine if this
macro
will always be zero. It would surely be convenient if it is but it
never
states this directly. the "zero or" part, leads me to believe that the
macro
can be something other than zero, but I'm not too sure.

You are correct. The wording of the standard does not dictate the
value of EXIT_SUCCESS, nor EXIT_FAILURE.

All you have to know is that 0 and EXIT_SUCCESS are functional
synonyms that denote successful program completion. In fact,
the value returned to the environment does necessarily have
to correspond to the value returned within the program. It
just has to indicate that the program completed successfully,
in an implementation defined manner.

Alex

 

[Ben Pfaff]

beyond this paragraph from the standard, I can't determine if
this macro will always be zero. It would surely be convenient
if it is but it never states this directly. the "zero or" part,
leads me to believe that the macro can be something other than
zero, but I'm not too sure.

The standard doesn't state or imply that EXIT_SUCCESS is always
0, so you can't portably depend on it.

 

[Keith Thompson]

You are correct. The wording of the standard does not dictate the
value of EXIT_SUCCESS, nor EXIT_FAILURE.

All you have to know is that 0 and EXIT_SUCCESS are functional
synonyms that denote successful program completion. In fact,
the value returned to the environment does necessarily have
to correspond to the value returned within the program. It
just has to indicate that the program completed successfully,
in an implementation defined manner.

0 and EXIT_SUCCESS aren't necessarily synonymous (though the wording
in the standard could be read to indicate that they are). They could
indicate different kinds of success. Of course, a portable program
can't make use of the distinction, if any.

 

[nobody]

The standard doesn't state or imply that EXIT_SUCCESS is always
0, so you can't portably depend on it.

7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
-----------------------------------------^^^^^^^^^^^^^^^^^^^^
an implementation-defined form of the status successful
termination is returned. ...

5.1.2.2.3p1 ... reaching the } that terminates the main
function returns a value of 0. ...

If those two together are not "statement", aren't they
at least implication?

Related question of my own (I asked about this topic
some months ago and don't want to seem obtuse - just want
to understand issues). Standard talks about returning to
the host environment. Only way I know of to (portably?)
execute another (C) program from C program is system()
call. However, 7.20.4.5p3 states (about system()) "If the
argument is not a null pointer, and the system function
does return, it returns an implementation-defined value."
Doesn't it all together imply that success/failure of
a C program can be portably "returned", but not "retrieved"
(in a portable manner)? If yes, then *portable* "return to
host environment" doesn't make much sense, does it? (I'm
not interested in portable return to e.g. Java program).
(If no,) I will really appreciate clarification (as
always, even if I don't state so).
Thanks. (It's not sig, I'm not impersonating Tom

 

[Ben Pfaff]

7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
-----------------------------------------^^^^^^^^^^^^^^^^^^^^
an implementation-defined form of the status successful
termination is returned. ...

If EXIT_SUCCESS is always zero, then why the "or"?

5.1.2.2.3p1 ... reaching the } that terminates the main
function returns a value of 0. ...

Nothing to do with the former statement.

If those two together are not "statement", aren't they
at least implication?

No.

 

[Arthur J. O'Dwyer]

If EXIT_SUCCESS is always zero, then why the "or"?

[Because it is possible that (EXIT_SUCCESS != 0).]

No.

I see the problem here. IMHO, EXIT_SUCCESS and zero *are*
synonymous *in the context of a call to exit()*. Note that
I've added a line under the word "the" in 7.20.4.3p5, which
to me indicates that there is only one possible status
"successful termination" in C, and it's triggered by both
0 and EXIT_SUCCESS, equivalently.
However, 0 and EXIT_SUCCESS are obviously *not* equivalent
in all contexts. To take the canonical extreme example,

void *p = 0;
void *q = EXIT_SUCCESS;

are certainly not equivalent! But I do believe the Standard
guarantees that

exit(0);
exit(EXIT_SUCCESS);

are exactly equivalent under all implementations, no matter
the actual integer value of EXIT_SUCCESS.

-Arthur

 

[Douglas A. Gwyn]

5.1.2.2.3p1 ... reaching the } that terminates the main
function returns a value of 0. ...

which is one form of returning a successful termination
status to the invoking environment. EXIT_STATUS could
have a value different from 0, and in fact it did on
VAX/VMS at one point in time (the system convention was
that even-values status returns indicated failure and
odd-values ones success, but since there was no failure
code 0 the C run-time system was able to convert any 0
return into an odd value before handing it back to the
environment).

Doesn't it all together imply that success/failure of
a C program can be portably "returned", but not "retrieved"
(in a portable manner)? If yes, then *portable* "return to
host environment" doesn't make much sense, does it? (I'm
not interested in portable return to e.g. Java program).

It makes plenty of sense, for example to use programs
properly in Unix shell scripts they must correctly
indicate whethr they succeeded or failed. Similarly
for other host command environments. There is more to
computing than just C.

 

[Mike Wahler]

If EXIT_SUCCESS is always zero, then why the "or"?

[Because it is possible that (EXIT_SUCCESS != 0).]

No.

I see the problem here. IMHO, EXIT_SUCCESS and zero *are*
synonymous *in the context of a call to exit()*. Note that
I've added a line under the word "the" in 7.20.4.3p5, which
to me indicates that there is only one possible status
"successful termination" in C, and it's triggered by both
0 and EXIT_SUCCESS, equivalently.
However, 0 and EXIT_SUCCESS are obviously *not* equivalent
in all contexts. To take the canonical extreme example,

void *p = 0;

Here, the 0 does not signify an integral zero, but a null pointer.

void *q = EXIT_SUCCESS;

The behavior of this is implementation defined.

are certainly not equivalent! But I do believe the Standard
guarantees that

exit(0);
exit(EXIT_SUCCESS);

are exactly equivalent under all implementations, no matter
the actual integer value of EXIT_SUCCESS.

Right, because in both these cases the argument is an integer
value, with the pointer examples above, it is not.

-Mike

 

[Dan Pop]

Finally, control is returned to the host environment. If the value of
status is zero or EXIT_SUCCESS, an implementation-defined form of the
status successful termination is returned.

beyond this paragraph from the standard, I can't determine if this
macro
will always be zero. It would surely be convenient if it is but it
never
states this directly. the "zero or" part, leads me to believe that the
macro
can be something other than zero, but I'm not too sure.

Please explain why do you think it matters whether EXIT_SUCCESS can be
something else than zero or not. Are you planning to use EXIT_SUCCESS
instead of zero in other contexts than exit() calls?

Dan

 

[Dan Pop]

0 and EXIT_SUCCESS aren't necessarily synonymous (though the wording
in the standard could be read to indicate that they are).

Then, how do you know they aren't? The most natural interpretation of
the text is that they have the *same* effect.

They could indicate different kinds of success.

This is far from obvious from the standard.

Of course, a portable program
can't make use of the distinction, if any.

Especially since the distinction (if any) happens *after* the program
termination ;-)

Dan

 

[Wojtek Lerch]

Here, the 0 does not signify an integral zero, but a null pointer.


The behavior of this is implementation defined.

If the value is nonzero, this is a constraint violation.

And I don't think the value of EXIT_SUCCESS is implementation-defined. At
least as far as I can tell, the standard never says that it is. Doesn't
that make it unspecified?

Right, because in both these cases the argument is an integer
value, with the pointer examples above, it is not.

But where does the standard say it's *exactly* equivalent? If an
implementation detects the difference and displays slightly different
messages on the terminal (e.g. "Successful termination (0)" vs. "Successful
termination (EXIT_SUCCESS)"), how does that make it non-conforming?

 

[James Kuyper]

7.20.4.3p5 ... If the value of status is zero or EXIT_SUCCESS,
-----------------------------------------^^^^^^^^^^^^^^^^^^^^
an implementation-defined form of the status successful
termination is returned. ...

5.1.2.2.3p1 ... reaching the } that terminates the main
function returns a value of 0. ...

If those two together are not "statement", aren't they
at least implication?

They are statements, but they don't imply that EXIT_SUCCESS is always
zero. In fact, the "or" strongly implies that EXIT_SUCCESS doesn't have
to be the same as zero.

Related question of my own (I asked about this topic
some months ago and don't want to seem obtuse - just want
to understand issues). Standard talks about returning to
the host environment. Only way I know of to (portably?)
execute another (C) program from C program is system()
call. However, 7.20.4.5p3 states (about system()) "If the
argument is not a null pointer, and the system function
does return, it returns an implementation-defined value."

Doesn't it all together imply that success/failure of
a C program can be portably "returned", but not "retrieved"
(in a portable manner)? If yes, then *portable* "return to
host environment" doesn't make much sense, does it? (I'm
not interested in portable return to e.g. Java program).

Correct. Code of that kind cannot be written to be portable across all
environments where the C standard is the only one you can rely on.
However, if you restrict yourself to a narrower range of environments,
where stronger guarantees by other standards (such as POSIX) apply, then
it can be portable.

 

[Arthur J. O'Dwyer]

Yes, it was a poor example. A better example would have been

if (EXIT_SUCCESS != 0)
puts("Hello");

....but that's kind of boring, isn't it?

If the value is nonzero, this is a constraint violation.
Right.

And I don't think the value of EXIT_SUCCESS is implementation-defined. At
least as far as I can tell, the standard never says that it is. Doesn't
that make it unspecified?

Nope. "Unspecified," in a C context, means that there are only a few
well-specified alternatives, and that the implementation must pick
one of them. "Implementation-defined" means that the implementation
has free range to define EXIT_SUCCESS however it likes, within certain
parameters. As I read the Standard, the value of EXIT_SUCCESS is
implementation-defined.

But where does the standard say it's *exactly* equivalent? If an
implementation detects the difference and displays slightly different
messages on the terminal (e.g. "Successful termination (0)" vs. "Successful
termination (EXIT_SUCCESS)"), how does that make it non-conforming?

IMO, that would violate the sentence whose operative word I
specifically underlined in the original quote:

[#5] Finally, control is returned to the host environment.
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. ^^^

If the platform has more than one traditional form of the "status
successful" termination, it must *pick one* to be *the* status
successful termination for its C implementation. You can't have
two different "*the* status successful terminations"!

-Arthur

 

[Keith Thompson]

Nope. "Unspecified," in a C context, means that there are only a few
well-specified alternatives, and that the implementation must pick
one of them. "Implementation-defined" means that the implementation
has free range to define EXIT_SUCCESS however it likes, within certain
parameters. As I read the Standard, the value of EXIT_SUCCESS is
implementation-defined.

"Implementation-defined" also means that the implementation has to
document the choice it makes. There's no requirement to document the
value of EXIT_SUCCESS.

[...]

But where does the standard say it's *exactly* equivalent? If an
implementation detects the difference and displays slightly different
messages on the terminal (e.g. "Successful termination (0)" vs. "Successful
termination (EXIT_SUCCESS)"), how does that make it non-conforming?

IMO, that would violate the sentence whose operative word I
specifically underlined in the original quote:

[#5] Finally, control is returned to the host environment.
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. ^^^

If the platform has more than one traditional form of the "status
successful" termination, it must *pick one* to be *the* status
successful termination for its C implementation. You can't have
two different "*the* status successful terminations"!

It's clear that EXIT_SUCCESS can have a value other than 0. It's not
entirely clear, at least to me, that exit(0) and exit(EXIT_SUCCESS)
are entirely equilvalent. The standard refers to "*the* status
successful termination", but also refers to "*an*
implementation-defined form" of that status. In my opinion, the
quoted paragraph can be interpreted to allow 0 and EXIT_SUCCESS to
indicate two different forms of "the status successful termination".
In other words:

If the value of status is zero, an implementation-defined form of
the status successful termination is returned. If the value of
status is EXIT_SUCCESS, an implementation-defined form of the
status successful termination is returned.

I agree that it could also be read to require both to return the same
form of the status successful termination, but I think my
interpretation makes more sense, especially in environment (like VMS)
with multiple ways to indicate success. (On the other hand, there's
no portable way to take advantage of any difference between exit(0)
and exit(EXIT_SUCCESS). If the authors of the standard had wanted to
guarantee that exit(0) and exit(EXIT_SUCCESS) are exactly equivalent,
they could have required that EXIT_SUCCESS == 0.

 

[Mike Wahler]

In other words:

If the value of status is zero, an implementation-defined form of
the status successful termination is returned. If the value of
status is EXIT_SUCCESS, an implementation-defined form of the
status successful termination is returned.

I agree that it could also be read to require both to return the same
form of the status successful termination, but I think my
interpretation makes more sense, especially in environment (like VMS)
with multiple ways to indicate success. (On the other hand, there's
no portable way to take advantage of any difference between exit(0)
and exit(EXIT_SUCCESS). If the authors of the standard had wanted to
guarantee that exit(0) and exit(EXIT_SUCCESS) are exactly equivalent,
they could have required that EXIT_SUCCESS == 0.

In which case there would have been no need to define
the 'EXIT_SUCCESS' macro at all.

-Mike

 

[James Kuyper]

Nope. "Unspecified," in a C context, means that there are only a few
well-specified alternatives, and that the implementation must pick
one of them. "Implementation-defined" means that the implementation
has free range to define EXIT_SUCCESS however it likes, within certain
parameters. As I read the Standard, the value of EXIT_SUCCESS is
implementation-defined.

Implementation-defined is a subset of "unspecified". The alternatives
for "unspecified" are not required to be "few", the only requirement is
that there be at least two of them. In this case, EXIT_SUCCESS can be
defined as expanding into any string of characters that constitutes an
integer constant expression that can be safely converted to an int; the
expression's value need not itself be within the valid range of an int.
There is a discrete infinity of such expressions, which becomes finite,
but still huge, if you put an upper limit on the length of that
character string.

 

[Mantorok Redgormor]

Please explain why do you think it matters whether EXIT_SUCCESS can be
something else than zero or not. Are you planning to use EXIT_SUCCESS
instead of zero in other contexts than exit() calls?

Dan

well I was using EXIT_FAILURE in a few functions to serve as a
failure returned. which is why I was ensuring if EXIT_SUCCESS
is guaranteed to be zero, which it isn't. So that route is messy.

I guess I could instead use

#define FAILURE 1
#define SUCCESS 0

 

[Eric Sosman]

well I was using EXIT_FAILURE in a few functions to serve as a
failure returned. which is why I was ensuring if EXIT_SUCCESS
is guaranteed to be zero, which it isn't. So that route is messy.

Also dangerous, at least in theory. As far as I can
tell, the Standard permits EXIT_FAILURE == EXIT_SUCCESS
on an implementation where programs don't have a termination
status at all and the "implementation-defined form" thereof
is vacuous.

I guess I could instead use

#define FAILURE 1
#define SUCCESS 0

Or something like that. It's a little counter-intuitive
that `if (FAILURE)' tests out as true, so it's probably best
to form the habit of writing `if (func() == SUCCESS)' instead.

 

[Tim Woodall]

If the value is nonzero, this is a constraint violation.

Why? It must be an integer (or convert to an integer) in order for
it to be a valid return from main. And integers can be converted
to pointers in an implementation defined way.

Tim.