Reversed 2.04 introduction of the term "process termination function".

Minor rewording and formatting fixes.
This commit is contained in:
Michael Kerrisk 2005-06-23 09:47:01 +00:00
parent 18f2ce4067
commit a210091ced
1 changed files with 23 additions and 20 deletions

View File

@ -30,33 +30,36 @@ exit \- cause normal process termination
.BI "void exit(int " status );
.fi
.SH DESCRIPTION
The \fBexit()\fP function causes normal process termination and the
the value of \fIstatus & 0377\fP is returned to the parent
The \fBexit\fP() function causes normal process termination and the
value of \fIstatus & 0377\fP is returned to the parent
(see
.BR wait (2)).
All process termination functions registered with
\fBatexit()\fP and \fBon_exit()\fP
are called, in the reverse order of their registration,
and all open streams are flushed and closed.
Files created by \fItmpfile()\fP are removed.
.LP
The C standard specifies two constants
\fIEXIT_SUCCESS\fP and \fIEXIT_FAILURE\fP
that may be passed to \fBexit()\fP to indicate successful or unsuccessful
All functions registered with
\fBatexit\fP() and \fBon_exit\fP()
are called, in the reverse order of their registration.
(It is possible for one of these functions to use
\fBatexit\fP() or \fBon_exit\fP() to register an additional
function to be executed during exit processing;
the new registration is added to the front of the list of functions
that remain to be called.)
.LP
All open streams are flushed and closed.
Files created by \fBtmpfile\fP() are removed.
.LP
The C standard specifies two constants,
\fIEXIT_SUCCESS\fP and \fIEXIT_FAILURE\fP,
that may be passed to \fBexit\fP() to indicate successful or unsuccessful
termination, respectively.
.SH "RETURN VALUE"
The \fBexit()\fP function does not return.
The \fBexit\fP() function does not return.
.SH "CONFORMING TO"
SVID 3, POSIX, BSD 4.3, ISO 9899 (``ANSI C'')
.SH NOTES
During exit processing, a process termination function may
register additional process termination
functions with \fBatexit()\fP and \fBon_exit()\fP.
These functions are added to the front of the list of
process termination functions that remain to be called.
.LP
It is undefined what happens if one of the process termination
functions calls either \fBexit()\fP or \fBlongjmp()\fP.
It is undefined what happens if one of the
functions registered using \fBatexit\fP() and \fBon_exit\fP()
calls either \fBexit\fP() or \fBlongjmp\fP().
.LP
The use of EXIT_SUCCESS and EXIT_FAILURE is slightly more portable
(to non-Unix environments) than that of 0 and some non-zero value
@ -65,7 +68,7 @@ like 1 or \-1. In particular, VMS uses a different convention.
BSD has attempted to standardize exit codes - see the file
.IR <sysexits.h> .
.LP
After \fBexit()\fP, the exit status must be transmitted to the
After \fBexit\fP(), the exit status must be transmitted to the
parent process. There are three cases. If the parent has set
SA_NOCLDWAIT, or has set the SIGCHLD handler to SIG_IGN, the
status is discarded. If the parent was waiting on the child
@ -75,7 +78,7 @@ it is not interested in the exit status, but is not waiting,
the exiting process turns into a "zombie" process
(which is nothing but a container for the single byte representing
the exit status) so that the parent can learn the exit status when
it later calls one of the \fIwait()\fP functions.
it later calls one of the \fIwait\fP() functions.
.LP
If the implementation supports the SIGCHLD signal, this signal
is sent to the parent. If the parent has set SA_NOCLDWAIT,