EXIT_SUCCESS guaranteed to always be zero?

J

James Kuyper

Tim said:
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.
 
D

Dan Pop

In said:
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
 
N

nobody

Ben Pfaff said:
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.
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.)

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

Zack Weinberg

nobody said:
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
 
D

Dan Pop

In said:
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
 
G

Grumble

James said:
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 :-þ
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top