exit() values and the C standards?

[Zach]

[semantics of argument to the exit function]

Or do both standards only define the constants EXIT_SUCCESS and
EXIT_FAILURE and most compiler implementations associate 0 with
EXIT_SUCCESS and 1 with EXIT_FAILURE? Which standard should I follow
in general practice?

Both C89 and C99 have the same wording in this area:

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

My guess is that 0 for EXIT_SUCCESS and 1 for EXIT_FAILURE is
most common. POSIX requires that EXIT_SUCCESS be 0 (but only
requires that EXIT_FAILURE be nonzero, not that it be 1).

Also, I've seen in code other values such as:
exit(3);

What do these other values (besides 0 and 1) indicate specifically and
which should I use to have good, portable C code?

The meaning of other status values is implementation defined. I
would use one of the standard exit codes in portable C code.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

Hi Ben,

Cool .sig BTW Thanks. I heard you wrote a C book, is it still
available?

Zach

 

[James Kuyper]

you get implementation defined behavior.


In windows or dos the exit value winds up in ERRORLEVEL.
In unix it's pretty-much the same but the return value
isn't called errorlevel.

In Unix, the lower 8 bits of the value returned by exit() can be
collected by the parent process from the return value of one of the
wait() family of system calls. When the parent process is one of usual
shells, the status of the most recently executed command is available in
the shell variable $?.

 

[Dag-Erling Smørgrav]

There's an attempt at standardizing exit codes for system (commonly
network) programs in <sysexits.h>. If you look at the codes you
will see that these exit codes are most unsuited for exit codes
from C compilers.

<sysexits.h> is pretty much just a list of exit codes used by sendmail.

DES

 

[Kaz Kylheku]

There's an attempt at standardizing exit codes for system (commonly
network) programs in <sysexits.h>.

I do not see this header listed in the online version of Issue 6
of The Single Unix Specification.

http://www.opengroup.org/onlinepubs/000095399/

There a link ``13. Headers'' to navigate to a table headers, in the bottom left
frame.

This header seems to have evaded formal standardization.

 

[Dag-Erling Smørgrav]

<sysexits.h> is pretty much just a list of exit codes used by
sendmail.

It's not quite that bad; within the FreeBSD source I see these
programs that are unrelated to mail delivery using them [...]

Yes, in violation of the project's coding standard.

DES

 

[Jorgen Grahn]

....
Other values indicate specifically what the application documented
specifically. Under UNIX there are some file comparison commands
(e.g. cmp, diff, rcsdiff) that need 3 exit codes: files equal (0),
files differrent (1) and unable to make comparison, such as not
being able to open the files (anything else)

In Unix general wisdom is 0 means success, 1 failure, and if you
/really/ need it, use some other smallish values as exit codes.
I do not see EXIT_SUCCESS/FAILURE used very often.

....

Incidentally, there is *NO* convention that you should use exit(errno)
on seeing an error. errno is too often zero, and there's no value
of errno for "missing command-line parameter".

Fortunately, I have never seen that at all. In practice, almost all
the time, the caller only needs to know if the program succeeded or not.

/Jorgen

 

[Guest]

In Unix general wisdom is 0 means success, 1 failure, and if you
/really/ need it, use some other smallish values as exit codes.
I do not see EXIT_SUCCESS/FAILURE used very often.


Fortunately, I have never seen that at all. In practice, almost all
the time, the caller only needs to know if the program succeeded or not.

you are posting to a two month old thread,
what do you think you are adding?

 

[CBFalconer]

.... snip ...

In Unix general wisdom is 0 means success, 1 failure, and if you
/really/ need it, use some other smallish values as exit codes.
I do not see EXIT_SUCCESS/FAILURE used very often.

No no no. C runs on many systems other than Unix. Why cripple
your software? You have the values 0 (always available) and
EXIT_SUCCESS and EXIT_FAILURE (after #include <stdlib.h>). These
are specified by the C standard, and should be available anywhere.
Also, this is comp.lang.c, and such C extensions supplied by
specific systems are off-topic. Your answer is fine for
comp.unix.programmer.

 

[vippstar]

CBFalconer said:

s/should/are/

"and are be available anywhere"?

 

[Beej Jorgensen]

Do you think that telling him this will magically change the entire
Unix world over to using portable return values?

When rsync (with its 20 different exit values) does it, then you'll know
everyone has.

But while we're on it, if a strictly-conforming program can't produce
output dependent on any implementation-defined behavior, and exit()
always returns an implementation-defined form of the status to the host
environment...

Maybe the exit status doesn't count as "output" since the program's
effectively done at that point...?

-Beej

 

[Antoninus Twink]

Why cripple your software? You have the values 0 (always available)
and EXIT_SUCCESS and EXIT_FAILURE (after #include <stdlib.h>).

My god, Falconer, you really are so ignorant it hurts.

Are you honestly trying to claim that grep is "crippled" by being able
to return distinct exit values for the three separate cases "found",
"not found", and "error"? If so, you're completely crazy.

Exactly the opposite is true - without the possibility for programs to
return several meaningful exit status codes, glue languages like shell
scripts or Perl (or indeed C with fork()/exec()) are crippled, since
they're prevented from performing robust error handling.

Idiot.

 

[Beej Jorgensen]

That has been debated on this newsgroup and comp.std.c many times in
the past.

D'oh. Apologies.

The standard doesn't define "output", so we're left to fall back on the
definition given in ISO/IEC 2382-1.

Thanks for the answer, all the same.

(Besides, arguing that "a strictly conforming program can't exit" really
must be contrary to the thinking behind the spec.

-Beej

 

[James Kuyper]

Beej Jorgensen wrote:
....

(Besides, arguing that "a strictly conforming program can't exit" really
must be contrary to the thinking behind the spec.

Not everything that was written in the standard matches the intent of
the authors. This should not be taken as criticism of the authors, who
worked very hard to produce a document that explains a very complex set
of ideas; that it has as few defects as it does is actually pretty
remarkable. Most of the defects that remain after numerous DRs have been
resolved are pretty intractable - I can recognize that they are defects,
but have been unable to suggest alternative wording that is not also
defective, in a different way.

The section that defines what conformance means is one of the trickiest
in the standard, in that regard.

 

[lawrence.jones]

There are roughly two schools of thought on comp.lang.c/comp.std.c
when it comes to the standard: what the standard intended and what
the standard says. People who belong to the former school seem to be
mostly committee members who expect the general public to be
able to read minds. On the other hand, people who belong to the
latter school seem to be mostly pedants who expect the English
language to be able to do far more than it can.

As a self-professed member of the former group, I'll accept that
description as containing only a moderate amount of hyperbole. The
description of the second group, of course, is spot on. ;-)

I've argued that
only a formal semantics can bridge the divide between the two
groups.

Which would have the added benefit that no one would be able to
understand it sufficiently to argue about it.