EXIT_SUCCESS guaranteed to always be zero?

In comp.lang.c Mantorok Redgormor <ne*****@tokyo.com> wrote:

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

ne*****@tokyo.com (Mantorok Redgormor) writes:

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.
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

Alex <al*******@hotmail.com> writes:

In comp.lang.c Mantorok Redgormor <ne*****@tokyo.com> wrote:

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.

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_Keith) ks***@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)

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

ne*****@tokyo.com (Mantorok Redgormor) writes:

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.

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

"nobody" <no****@nowhere.non> writes:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

ne*****@tokyo.com (Mantorok Redgormor) writes:

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.

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.
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield

On Tue, 24 Nov 2003, Ben Pfaff wrote:

"nobody" <no****@nowhere.non> writes:

"Ben Pfaff" <bl*@cs.stanford.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. ... ^^^

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

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

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

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

nobody wrote:

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.

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi***********************************@unix46. andrew.cmu.edu...

On Tue, 24 Nov 2003, Ben Pfaff wrote:

"nobody" <no****@nowhere.non> writes:

"Ben Pfaff" <bl*@cs.stanford.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. ... ^^^
If EXIT_SUCCESS is always zero, then why the "or"?

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

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

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

In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:

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

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:L9*******************@newsread1.news.pas.eart hlink.net...

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi***********************************@unix46. andrew.cmu.edu...

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.

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?

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.

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?

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Alex <al*******@hotmail.com> writes:

In comp.lang.c Mantorok Redgormor <ne*****@tokyo.com> wrote:

> 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.

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

nobody wrote:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu... ....

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?

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.

On Tue, 25 Nov 2003, Wojtek Lerch wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote...

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote...

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

void *q = EXIT_SUCCESS;

The behavior of this is implementation defined.

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.

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.

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

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Tue, 25 Nov 2003, Wojtek Lerch wrote:

[...]

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.

"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.

--
Keith Thompson (The_Other_Keith) ks***@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)

"Arthur J. O'Dwyer" wrote:

On Tue, 25 Nov 2003, Wojtek Lerch wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote...

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote...

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.

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.

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

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

Da*****@cern.ch (Dan Pop) wrote in message news:<bp**********@sunnews.cern.ch>...

In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:

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

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
--
nethlek

Mantorok Redgormor wrote:

Da*****@cern.ch (Dan Pop) wrote:

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.

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.

--
Er*********@sun.com

On Tue, 25 Nov 2003 14:30:38 GMT,
Wojtek Lerch <Wo******@yahoo.ca> wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:L9*******************@newsread1.news.pas.eart hlink.net...

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi***********************************@unix46. andrew.cmu.edu...

> void *q = EXIT_SUCCESS;

The behavior of this is implementation defined.

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.

--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/

Tim Woodall wrote:

On Tue, 25 Nov 2003 14:30:38 GMT,
Wojtek Lerch <Wo******@yahoo.ca> wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:L9*******************@newsread1.news.pas.eart hlink.net...

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi***********************************@unix46. andrew.cmu.edu...

> void *q = EXIT_SUCCESS;

The behavior of this is implementation defined.

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.

Section 6.5.4p3: "Conversions that involve pointers, other than where
permitted by the constraints of 6.5.16.1, shall be specified by means of
an explicit cast." If EXIT_SUCCESS has a value of 0, then it counts as a
null pointer constant, which is permitted by 6.5.16.1. Otherwise, the
absence of an explicit cast is indeed a constraint violation.

Even if you change the code to use an explicit cast, one remaining
potential problem applies. Per section 6.3.2.3p6: "... Except as
previously specified, the result is implementation-defined, might not be
correctly aligned, might not point to an entity of the referenced type,
and might be a trap representation."

Per footnote 41, a trap representation can be stored in 'q', but any
attempt to actually use the value of 'q' has undefined behavior.
Footnotes aren't normative, but this one correctly summarizes the
consequences of normative text in the standard.

In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bp**********@sunnews.cern.ch>...

In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:

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

well I was using EXIT_FAILURE in a few functions to serve as a
failure returned.

That's a bad idea. EXIT_FAILURE has well defined semantics *only* as
argument to an exit function call.
which is why I was ensuring if EXIT_SUCCESS
is guaranteed to be zero, which it isn't. So that route is messy.
All three can be defined as zero, if the execution environment does not
support the concept of program exit status.
I guess I could instead use

#define FAILURE 1
#define SUCCESS 0

Or, even better:

#define FAILURE 0
#define SUCCESS 1

but there is no consensus on that. Unix programmers may prefer

#define FAILURE -1
#define SUCCESS 0

for consistency with the Unix system calls.

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

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

"nobody" <no****@nowhere.non> writes:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

ne*****@tokyo.com (Mantorok Redgormor) writes:

> 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.

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"?

To imply that EXIT_SUCCESS (integer constant expression
after expansion) is "synonym" for literal 0. I would agree,
if it said (7 or 55 or 123). But I'm not native (English
speaker), so I won't argue.

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

Nothing to do with the former statement.

So this case (fall through) is a successful termination or
an unsuccessful one?
(Though not explicitly stated, I read it as successful,
together with quote above that gives me that EXIT_SUCCESS
evaluates to 0. But I'm known to err on ocassion.)

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

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

Yeah. Especially true about C standard(s) :-)

"nobody" <no****@nowhere.non> writes:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

"nobody" <no****@nowhere.non> writes:

> "Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
> news:87************@pfaff.stanford.edu...
> > ne*****@tokyo.com (Mantorok Redgormor) writes:
> >
> > > 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.
>
> 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"?

To imply that EXIT_SUCCESS (integer constant expression
after expansion) is "synonym" for literal 0. I would agree,
if it said (7 or 55 or 123). But I'm not native (English
speaker), so I won't argue.

My interpretation: 7.20.4.3p5 says that there are two things you can
portably pass to exit(), which cause "successful termination" to be
returned to the surrounding environment. One is 0, and the other is
EXIT_SUCCESS. 7.20p1 says that EXIT_SUCCESS expands to an integer
constant expression, but the value of that expression is undefined.

If memory serves, at least some versions of VMS C defined EXIT_SUCCESS
to be 1.

You may be wondering 'why define EXIT_SUCCESS at all if 0 has the same
effect?' It is presumably for symmetry with EXIT_FAILURE. Also, the
fact that it might not be 0 is a caution to writers of portable code
not to use numeric arguments to exit() other than 0. The very common
convention of using exit(1) in Unix command line utilities to indicate
failure, for instance, is not portable; it would fail under those VMS C
versions discussed above.

zw

In <87************@egil.codesourcery.com> Zack Weinberg <za**@codesourcery.com> writes:

You may be wondering 'why define EXIT_SUCCESS at all if 0 has the same
effect?' It is presumably for symmetry with EXIT_FAILURE.

EXIT_SUCCESS is the C89 way of doing it, while 0 is obviously supported
because it was the (most common) existing practice. Things would
have been much clear if C89 deprecated the usage of 0 for this purpose.

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

James Kuyper wrote:

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.

I think you should lay off the -pedantic flag for a while :-þ