Adding upstream version 6.05.01.upstream/6.05.01

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 203 insertions, 0 deletions

diff --git a/man3/exit.3 b/man3/exit.3
new file mode 100644
index 0000000..f51c557
--- /dev/null
+++ b/man3/exit.3
@@ -0,0 +1,203 @@
+'\" t
+.\" Copyright (C) 2001 Andries Brouwer <aeb@cwi.nl>.
+.\"
+.\" SPDX-License-Identifier: Linux-man-pages-copyleft
+.\"
+.\" FIXME . There are a lot of other process termination actions that
+.\" could be listed on this page. See, for example, the list in the
+.\" POSIX exit(3p) page.
+.\"
+.TH exit 3 2023-07-20 "Linux man-pages 6.05.01"
+.SH NAME
+exit \- cause normal process termination
+.SH LIBRARY
+Standard C library
+.RI ( libc ", " \-lc )
+.SH SYNOPSIS
+.nf
+.B #include <stdlib.h>
+.PP
+.BI "[[noreturn]] void exit(int " status );
+.fi
+.SH DESCRIPTION
+The
+.BR exit ()
+function causes normal process termination and the least significant byte of
+.I status
+(i.e., \fIstatus & 0xFF\fP) is returned to the parent (see
+.BR wait (2)).
+.PP
+All functions registered with
+.BR atexit (3)
+and
+.BR on_exit (3)
+are called, in the reverse order of their registration.
+(It is possible for one of these functions to use
+.BR atexit (3)
+or
+.BR on_exit (3)
+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.)
+If one of these functions does not return
+(e.g., it calls
+.BR _exit (2),
+or kills itself with a signal),
+then none of the remaining functions is called,
+and further exit processing (in particular, flushing of
+.BR stdio (3)
+streams) is abandoned.
+If a function has been registered multiple times using
+.BR atexit (3)
+or
+.BR on_exit (3),
+then it is called as many times as it was registered.
+.PP
+All open
+.BR stdio (3)
+streams are flushed and closed.
+Files created by
+.BR tmpfile (3)
+are removed.
+.PP
+The C standard specifies two constants,
+\fBEXIT_SUCCESS\fP and \fBEXIT_FAILURE\fP,
+that may be passed to
+.BR exit ()
+to indicate successful or unsuccessful
+termination, respectively.
+.SH RETURN VALUE
+The
+.BR exit ()
+function does not return.
+.SH ATTRIBUTES
+For an explanation of the terms used in this section, see
+.BR attributes (7).
+.TS
+allbox;
+lbx lb lb
+l l l.
+Interface	Attribute	Value
+T{
+.na
+.nh
+.BR exit ()
+T}	Thread safety	MT-Unsafe race:exit
+.TE
+.sp 1
+.PP
+The
+.BR exit ()
+function uses a global variable that is not protected,
+so it is not thread-safe.
+.SH STANDARDS
+C11, POSIX.1-2008.
+.SH HISTORY
+C89, POSIX.1-2001, SVr4, 4.3BSD.
+.SH NOTES
+The behavior is undefined if one of the functions registered using
+.BR atexit (3)
+and
+.BR on_exit (3)
+calls either
+.BR exit ()
+or
+.BR longjmp (3).
+Note that a call to
+.BR execve (2)
+removes registrations created using
+.BR atexit (3)
+and
+.BR on_exit (3).
+.PP
+The use of
+.B EXIT_SUCCESS
+and
+.B EXIT_FAILURE
+is slightly more portable
+(to non-UNIX environments) than the use of 0 and some nonzero value
+like 1 or \-1.
+In particular, VMS uses a different convention.
+.PP
+BSD has attempted to standardize exit codes
+(which some C libraries such as the GNU C library have also adopted);
+see the file
+.IR <sysexits.h> .
+.PP
+After
+.BR exit (),
+the exit status must be transmitted to the
+parent process.
+There are three cases:
+.IP \[bu] 3
+If the parent has set
+.BR SA_NOCLDWAIT ,
+or has set the
+.B SIGCHLD
+handler to
+.BR SIG_IGN ,
+the status is discarded and the child dies immediately.
+.IP \[bu]
+If the parent was waiting on the child,
+it is notified of the exit status and the child dies immediately.
+.IP \[bu]
+Otherwise,
+the child becomes a "zombie" process:
+most of the process resources are recycled,
+but a slot containing minimal information about the child process
+(termination status, resource usage statistics) is retained in process table.
+This allows the parent to subsequently use
+.BR waitpid (2)
+(or similar) to learn the termination status of the child;
+at that point the zombie process slot is released.
+.PP
+If the implementation supports the
+.B SIGCHLD
+signal, this signal
+is sent to the parent.
+If the parent has set
+.BR SA_NOCLDWAIT ,
+it is undefined whether a
+.B SIGCHLD
+signal is sent.
+.\"
+.SS Signals sent to other processes
+If the exiting process is a session leader and its controlling terminal
+is the controlling terminal of the session, then each process in
+the foreground process group of this controlling terminal
+is sent a
+.B SIGHUP
+signal, and the terminal is disassociated
+from this session, allowing it to be acquired by a new controlling
+process.
+.PP
+If the exit of the process causes a process group to become orphaned,
+and if any member of the newly orphaned process group is stopped,
+then a
+.B SIGHUP
+signal followed by a
+.B SIGCONT
+signal will be
+sent to each process in this process group.
+See
+.BR setpgid (2)
+for an explanation of orphaned process groups.
+.PP
+Except in the above cases,
+where the signalled processes may be children of the terminating process,
+termination of a process does
+.I not
+in general cause a signal to be sent to children of that process.
+However, a process can use the
+.BR prctl (2)
+.B PR_SET_PDEATHSIG
+operation to arrange that it receives a signal if its parent terminates.
+.SH SEE ALSO
+.BR _exit (2),
+.BR get_robust_list (2),
+.BR setpgid (2),
+.BR wait (2),
+.BR atexit (3),
+.BR on_exit (3),
+.BR tmpfile (3)