# HG changeset patch # User HackBot # Date 1459416590 0 # Node ID 84581528a29e74c3f439a9d2877ca29b461c4eb4 # Parent 0eae4b049f93e831cd7fe3a4df75999cbd820576 fetch http://pubs.opengroup.org/onlinepubs/009695399/functions/_Exit.html diff -r 0eae4b049f93 -r 84581528a29e _Exit.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/_Exit.html Thu Mar 31 09:29:50 2016 +0000 @@ -0,0 +1,427 @@ + + + + + + + + +exit + + + + + + +
The Open Group Base Specifications Issue 6
+IEEE Std 1003.1, 2004 Edition
+Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.
A newer edition of this document exists here
+ + +
+

NAME

+ +
exit, _Exit, _exit - terminate a process
+ +

SYNOPSIS

+ +
+

#include <stdlib.h>
+
+ void exit(int status);
+ void _Exit(int status);
+
+
+ #include <unistd.h>
+ void _exit(int status);
+

+
+ +

DESCRIPTION

+ +
+

For exit() and _Exit(): [CX] [Option Start] The functionality described on this reference page is aligned with the +ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume +of IEEE Std 1003.1-2001 defers to the ISO C standard. [Option End]

+ +

The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, [CX] [Option Start]  or any other value, though only the least significant 8 bits +(that is, status & 0377) shall be available to a waiting parent process. +"[Option

+ +

The exit() function shall first call all functions registered by atexit(), +in the reverse order of their registration, except that a function is called after any previously registered functions that had +already been called at the time it was registered. Each function is called as many times as it was registered. If, during the call +to any such function, a call to the longjmp() function is made that would terminate +the call to the registered function, the behavior is undefined.

+ +

If a function registered by a call to atexit() fails to return, the remaining +registered functions shall not be called and the rest of the exit() processing shall not be completed. If exit() is +called more than once, the behavior is undefined.

+ +

The exit() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove +all files created by tmpfile(). Finally, control shall be terminated with the +consequences described below.

+ +

[CX] [Option Start] The +_Exit() and _exit() functions shall be functionally equivalent. [Option End]

+ +

The _Exit() [CX] +"[Option  and _exit() [Option End] functions +shall not call functions registered with atexit() nor any registered signal handlers. +Whether open streams are flushed or closed, or temporary files are removed is implementation-defined. Finally, the calling process +is terminated with the consequences described below.

+ +

These functions shall terminate the calling process [CX] [Option Start]  with the following consequences:

+ +
+
Note:
+ +
These consequences are all extensions to the ISO C standard and are not further CX shaded. However, XSI extensions are +shaded.
+
+ + + + +
+ +

RETURN VALUE

+ +
+

These functions do not return.

+
+ +

ERRORS

+ +
+

No errors are defined.

+
+ +
+
The following sections are informative.
+ +

EXAMPLES

+ +
+

None.

+
+ +

APPLICATION USAGE

+ +
+

Normally applications should use exit() rather than _Exit() or _exit().

+
+ +

RATIONALE

+ +
+
Process Termination
+ +

Early proposals drew a distinction between normal and abnormal process termination. Abnormal termination was caused only by +certain signals and resulted in implementation-defined "actions", as discussed below. Subsequent proposals distinguished three +types of termination: normal termination (as in the current specification), simple abnormal termination, and +abnormal termination with actions. Again the distinction between the two types of abnormal termination was that they were +caused by different signals and that implementation-defined actions would result in the latter case. Given that these actions were +completely implementation-defined, the early proposals were only saying when the actions could occur and how their occurrence could +be detected, but not what they were. This was of little or no use to conforming applications, and thus the distinction is not made +in this volume of IEEE Std 1003.1-2001.

+ +

The implementation-defined actions usually include, in most historical implementations, the creation of a file named core +in the current working directory of the process. This file contains an image of the memory of the process, together with +descriptive information about the process, perhaps sufficient to reconstruct the state of the process at the receipt of the +signal.

+ +

There is a potential security problem in creating a core file if the process was set-user-ID and the current user is not +the owner of the program, if the process was set-group-ID and none of the user's groups match the group of the program, or if the +user does not have permission to write in the current directory. In this situation, an implementation either should not create a +core file or should make it unreadable by the user.

+ +

Despite the silence of this volume of IEEE Std 1003.1-2001 on this feature, applications are advised not to create +files named core because of potential conflicts in many implementations. Some implementations use a name other than +core for the file; for example, by appending the process ID to the filename.

+ +
Terminating a Process
+ +

It is important that the consequences of process termination as described occur regardless of whether the process called +_exit() (perhaps indirectly through exit()) or instead was terminated due to a signal or for some other reason. Note +that in the specific case of exit() this means that the status argument to exit() is treated in the same way +as the status argument to _exit().

+ +

A language other than C may have other termination primitives than the C-language exit() function, and programs written +in such a language should use its native termination primitives, but those should have as part of their function the behavior of +_exit() as described. Implementations in languages other than C are outside the scope of this version of this volume of +IEEE Std 1003.1-2001, however.

+ +

As required by the ISO C standard, using return from main() has the same behavior (other than with respect to +language scope issues) as calling exit() with the returned value. Reaching the end of the main() function has the +same behavior as calling exit(0).

+ +

A value of zero (or EXIT_SUCCESS, which is required to be zero) for the argument status conventionally indicates +successful termination. This corresponds to the specification for exit() in the ISO C standard. The convention is +followed by utilities such as make and various shells, which interpret a zero status +from a child process as success. For this reason, applications should not call exit(0) or _exit(0) when they +terminate unsuccessfully; for example, in signal-catching functions.

+ +

Historically, the implementation-defined process that inherits children whose parents have terminated without waiting on them is +called init and has a process ID of 1.

+ +

The sending of a SIGHUP to the foreground process group when a controlling process terminates corresponds to somewhat different +historical implementations. In System V, the kernel sends a SIGHUP on termination of (essentially) a controlling process. In 4.2 +BSD, the kernel does not send SIGHUP in a case like this, but the termination of a controlling process is usually noticed by a +system daemon, which arranges to send a SIGHUP to the foreground process group with the vhangup() function. However, in 4.2 +BSD, due to the behavior of the shells that support job control, the controlling process is usually a shell with no other processes +in its process group. Thus, a change to make _exit() behave this way in such systems should not cause problems with existing +applications.

+ +

The termination of a process may cause a process group to become orphaned in either of two ways. The connection of a process +group to its parent(s) outside of the group depends on both the parents and their children. Thus, a process group may be orphaned +by the termination of the last connecting parent process outside of the group or by the termination of the last direct descendant +of the parent process(es). In either case, if the termination of a process causes a process group to become orphaned, processes +within the group are disconnected from their job control shell, which no longer has any information on the existence of the process +group. Stopped processes within the group would languish forever. In order to avoid this problem, newly orphaned process groups +that contain stopped processes are sent a SIGHUP signal and a SIGCONT signal to indicate that they have been disconnected from +their session. The SIGHUP signal causes the process group members to terminate unless they are catching or ignoring SIGHUP. Under +most circumstances, all of the members of the process group are stopped if any of them are stopped.

+ +

The action of sending a SIGHUP and a SIGCONT signal to members of a newly orphaned process group is similar to the action of 4.2 +BSD, which sends SIGHUP and SIGCONT to each stopped child of an exiting process. If such children exit in response to the SIGHUP, +any additional descendants receive similar treatment at that time. In this volume of IEEE Std 1003.1-2001, the signals +are sent to the entire process group at the same time. Also, in this volume of IEEE Std 1003.1-2001, but not in 4.2 BSD, +stopped processes may be orphaned, but may be members of a process group that is not orphaned; therefore, the action taken at +_exit() must consider processes other than child processes.

+ +

It is possible for a process group to be orphaned by a call to setpgid() or setsid(), as well as by process termination. This volume of +IEEE Std 1003.1-2001 does not require sending SIGHUP and SIGCONT in those cases, because, unlike process termination, +those cases are not caused accidentally by applications that are unaware of job control. An implementation can choose to send +SIGHUP and SIGCONT in those cases as an extension; such an extension must be documented as required in <signal.h>.

+ +

The ISO/IEC 9899:1999 standard adds the _Exit() function that results in immediate program termination without +triggering signals or atexit()-registered functions. In +IEEE Std 1003.1-2001, this is equivalent to the _exit() function.

+
+ +

FUTURE DIRECTIONS

+ +
+

None.

+
+ +

SEE ALSO

+ +
+

atexit(), close(), fclose() +, longjmp(), posix_trace_shutdown(), posix_trace_trid_eventid_open(), semop(), shmget(), sigaction(), wait(), +waitid(), waitpid(), the Base Definitions volume of +IEEE Std 1003.1-2001, <stdlib.h>, <unistd.h>

+
+ +

CHANGE HISTORY

+ +
+

First released in Issue 1. Derived from Issue 1 of the SVID.

+
+ +

Issue 5

+ +
+

The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.

+ +

Interactions with the SA_NOCLDWAIT flag and SIGCHLD signal are further clarified.

+ +

The values of status from exit() are better described.

+
+ +

Issue 6

+ +
+

Extensions beyond the ISO C standard are marked.

+ +

The DESCRIPTION is updated for alignment with IEEE Std 1003.1j-2000 by adding semantics for typed memory.

+ +

The following changes are made for alignment with the ISO/IEC 9899:1999 standard:

+ + + +

The description of tracing semantics is added for alignment with IEEE Std 1003.1q-2000.

+ +

References to the wait3() function are removed.

+ +

IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/16 is applied, correcting grammar in the DESCRIPTION.

+
+ +
End of informative text.
+ +
+
+UNIX ® is a registered Trademark of The Open Group.
+POSIX ® is a registered Trademark of The IEEE.
+[ Main Index | XBD | XCU | XSH | XRAT +]
+ + +
+ + +