EXIT_SUCCESS guaranteed to always be zero?

Re: EXIT_SUCCESS guaranteed to always be zero?

In comp.lang.c Mantorok Redgormor <nethlek@tokyo. com> wrote:[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]

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

Re: EXIT_SUCCESS guaranteed to always be zero?

nethlek@tokyo.c om (Mantorok Redgormor) writes:
[color=blue]
> 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.[/color]

The standard doesn't state or imply that EXIT_SUCCESS is always
0, so you can't portably depend on it.
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

Re: EXIT_SUCCESS guaranteed to always be zero?

Alex <alex_lord@hotm ail.com> writes:[color=blue]
> In comp.lang.c Mantorok Redgormor <nethlek@tokyo. com> wrote:[color=green]
> > 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.[/color]
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

Re: EXIT_SUCCESS guaranteed to always be zero?

"Ben Pfaff" <blp@cs.stanfor d.edu> wrote in message
news:87ptfhp7ar .fsf@pfaff.stan ford.edu...[color=blue]
> nethlek@tokyo.c om (Mantorok Redgormor) writes:
>[color=green]
> > 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.[/color]
>
> The standard doesn't state or imply that EXIT_SUCCESS is always
> 0, so you can't portably depend on it.[/color]

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:-)

Re: EXIT_SUCCESS guaranteed to always be zero?

"nobody" <nobody@nowhere .non> writes:
[color=blue]
> "Ben Pfaff" <blp@cs.stanfor d.edu> wrote in message
> news:87ptfhp7ar .fsf@pfaff.stan ford.edu...[color=green]
> > nethlek@tokyo.c om (Mantorok Redgormor) writes:
> >[color=darkred]
> > > 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.[/color]
> >
> > The standard doesn't state or imply that EXIT_SUCCESS is always
> > 0, so you can't portably depend on it.[/color]
>
> 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. ...[/color]

If EXIT_SUCCESS is always zero, then why the "or"?
[color=blue]
> 5.1.2.2.3p1 ... reaching the } that terminates the main
> function returns a value of 0. ...[/color]

Nothing to do with the former statement.
[color=blue]
> If those two together are not "statement" , aren't they
> at least implication?[/color]

No.
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield

Re: EXIT_SUCCESS guaranteed to always be zero?


On Tue, 24 Nov 2003, Ben Pfaff wrote:[color=blue]
>
> "nobody" <nobody@nowhere .non> writes:[color=green]
> > "Ben Pfaff" <blp@cs.stanfor d.edu> wrote...[color=darkred]
> > >
> > > The standard doesn't state or imply that EXIT_SUCCESS is always
> > > 0, so you can't portably depend on it.[/color]
> >
> > 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. ... ^^^[/color]
>
> If EXIT_SUCCESS is always zero, then why the "or"?[/color]

[Because it is possible that (EXIT_SUCCESS != 0).]
[color=blue][color=green]
> > If those two together are not "statement" , aren't they
> > at least implication?[/color]
>
> No.[/color]

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_SUCCE SS);

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

-Arthur

Re: EXIT_SUCCESS guaranteed to always be zero?

nobody wrote:[color=blue]
> 5.1.2.2.3p1 ... reaching the } that terminates the main
> function returns a value of 0. ...[/color]

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).
[color=blue]
> 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).[/color]

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.

Re: EXIT_SUCCESS guaranteed to always be zero?


"Arthur J. O'Dwyer" <ajo@nospam.and rew.cmu.edu> wrote in message
news:Pine.LNX.4 .58-035.03112501372 60.18297@unix46 .andrew.cmu.edu ...[color=blue]
>
> On Tue, 24 Nov 2003, Ben Pfaff wrote:[color=green]
> >
> > "nobody" <nobody@nowhere .non> writes:[color=darkred]
> > > "Ben Pfaff" <blp@cs.stanfor d.edu> wrote...
> > > >
> > > > 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. ... ^^^[/color]
> >
> > If EXIT_SUCCESS is always zero, then why the "or"?[/color]
>
> [Because it is possible that (EXIT_SUCCESS != 0).]
>[color=green][color=darkred]
> > > If those two together are not "statement" , aren't they
> > > at least implication?[/color]
> >
> > No.[/color]
>
> 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;[/color]

Here, the 0 does not signify an integral zero, but a null pointer.
[color=blue]
> void *q = EXIT_SUCCESS;[/color]

The behavior of this is implementation defined.
[color=blue]
>
> are certainly not equivalent! But I do believe the Standard
> guarantees that
>
> exit(0);
> exit(EXIT_SUCCE SS);
>
> are exactly equivalent under all implementations , no matter
> the actual integer value of EXIT_SUCCESS.[/color]

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

-Mike

Re: EXIT_SUCCESS guaranteed to always be zero?

In <41ec7ac0.03112 41714.51823929@ posting.google. com> nethlek@tokyo.c om (Mantorok Redgormor) writes:
[color=blue]
>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.[/color]

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
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Re: EXIT_SUCCESS guaranteed to always be zero?

"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message
news:L9Ewb.1423 8$n56.10237@new sread1.news.pas .earthlink.net. ..[color=blue]
> "Arthur J. O'Dwyer" <ajo@nospam.and rew.cmu.edu> wrote in message
> news:Pine.LNX.4 .58-035.03112501372 60.18297@unix46 .andrew.cmu.edu ...[color=green]
> > However, 0 and EXIT_SUCCESS are obviously *not* equivalent
> > in all contexts. To take the canonical extreme example,
> >
> > void *p = 0;[/color]
>
> Here, the 0 does not signify an integral zero, but a null pointer.
>[color=green]
> > void *q = EXIT_SUCCESS;[/color]
>
> The behavior of this is implementation defined.[/color]

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?
[color=blue][color=green]
> > exit(0);
> > exit(EXIT_SUCCE SS);
> >
> > are exactly equivalent under all implementations , no matter
> > the actual integer value of EXIT_SUCCESS.[/color]
>
> Right, because in both these cases the argument is an integer
> value, with the pointer examples above, it is not.[/color]

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?

Re: EXIT_SUCCESS guaranteed to always be zero?

In <lny8u5uguf.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Alex <alex_lord@hotm ail.com> writes:[color=green]
>> In comp.lang.c Mantorok Redgormor <nethlek@tokyo. com> wrote:[color=darkred]
>> > 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.[/color]
>>[color=darkred]
>> > 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.[/color]
>>
>> 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.[/color]
>
>0 and EXIT_SUCCESS aren't necessarily synonymous (though the wording
>in the standard could be read to indicate that they are).[/color]

Then, how do you know they aren't? The most natural interpretation of
the text is that they have the *same* effect.
[color=blue]
>They could indicate different kinds of success.[/color]

This is far from obvious from the standard.
[color=blue]
>Of course, a portable program
>can't make use of the distinction, if any.[/color]

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Re: EXIT_SUCCESS guaranteed to always be zero?

nobody wrote:[color=blue]
>
> "Ben Pfaff" <blp@cs.stanfor d.edu> wrote in message
> news:87ptfhp7ar .fsf@pfaff.stan ford.edu...[/color]
....[color=blue][color=green]
> > The standard doesn't state or imply that EXIT_SUCCESS is always
> > 0, so you can't portably depend on it.[/color]
>
> 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?[/color]

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.
[color=blue]
> 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).[/color]

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.

Re: EXIT_SUCCESS guaranteed to always be zero?


On Tue, 25 Nov 2003, Wojtek Lerch wrote:[color=blue]
>
> "Mike Wahler" <mkwahler@mkwah ler.net> wrote...[color=green]
> > "Arthur J. O'Dwyer" <ajo@nospam.and rew.cmu.edu> wrote...[color=darkred]
> > >
> > > However, 0 and EXIT_SUCCESS are obviously *not* equivalent
> > > in all contexts. To take the canonical extreme example,
> > >
> > > void *p = 0;[/color]
> >
> > Here, the 0 does not signify an integral zero, but a null pointer.[/color][/color]

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? :)

[color=blue][color=green][color=darkred]
> > > void *q = EXIT_SUCCESS;[/color]
> >
> > The behavior of this is implementation defined.[/color]
>
> If the value is nonzero, this is a constraint violation.[/color]

Right.
[color=blue]
> 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?[/color]

Nope. "Unspecifie d," in a C context, means that there are only a few
well-specified alternatives, and that the implementation must pick
one of them. "Implementa tion-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.

[color=blue][color=green][color=darkred]
> > > exit(0);
> > > exit(EXIT_SUCCE SS);
> > >
> > > are exactly equivalent under all implementations , no matter
> > > the actual integer value of EXIT_SUCCESS.[/color]
> >
> > Right, because in both these cases the argument is an integer
> > value, with the pointer examples above, it is not.[/color]
>
> 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?[/color]

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

Re: EXIT_SUCCESS guaranteed to always be zero?

"Arthur J. O'Dwyer" <ajo@nospam.and rew.cmu.edu> writes:[color=blue]
> On Tue, 25 Nov 2003, Wojtek Lerch wrote:[/color]
[...][color=blue][color=green]
> > 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?[/color]
>
> Nope. "Unspecifie d," in a C context, means that there are only a few
> well-specified alternatives, and that the implementation must pick
> one of them. "Implementa tion-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.[/color]

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

[...][color=blue][color=green]
> > 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?[/color]
>
> 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"![/color]

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_SUCCE SS)
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_SUCCE SS). If the authors of the standard had wanted to
guarantee that exit(0) and exit(EXIT_SUCCE SS) are exactly equivalent,
they could have required that EXIT_SUCCESS == 0.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)