426 lines
24 KiB
HTML
426 lines
24 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>exit</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3"> <a name="exit"></a> <a name="tag_03_131"></a><!-- exit -->
|
|
<!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h4><a name="tag_03_131_01"></a>NAME</h4>
|
|
|
|
<blockquote>exit, _Exit, _exit - terminate a process</blockquote>
|
|
|
|
<h4><a name="tag_03_131_02"></a>SYNOPSIS</h4>
|
|
|
|
<blockquote class="synopsis">
|
|
<p><code><tt>#include <<a href="../basedefs/stdlib.h.html">stdlib.h</a>><br>
|
|
<br>
|
|
void exit(int</tt> <i>status</i><tt>);<br>
|
|
void _Exit(int</tt> <i>status</i><tt>);<br>
|
|
<br>
|
|
<br>
|
|
#include <<a href="../basedefs/unistd.h.html">unistd.h</a>><br>
|
|
void _exit(int</tt> <i>status</i><tt>);<br>
|
|
</tt></code></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_03"></a>DESCRIPTION</h4>
|
|
|
|
<blockquote>
|
|
<p>For <i>exit</i>() and <i>_Exit</i>(): <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> 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. <img src="../images/opt-end.gif" alt="[Option End]" border=
|
|
"0"></p>
|
|
|
|
<p>The value of <i>status</i> may be 0, EXIT_SUCCESS, EXIT_FAILURE, <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img
|
|
src="../images/opt-start.gif" alt="[Option Start]" border="0"> or any other value, though only the least significant 8 bits
|
|
(that is, <i>status</i> & 0377) shall be available to a waiting parent process. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
|
|
<p>The <i>exit</i>() function shall first call all functions registered by <a href="../functions/atexit.html"><i>atexit</i>()</a>,
|
|
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 <a href="../functions/longjmp.html"><i>longjmp</i>()</a> function is made that would terminate
|
|
the call to the registered function, the behavior is undefined.</p>
|
|
|
|
<p>If a function registered by a call to <a href="../functions/atexit.html"><i>atexit</i>()</a> fails to return, the remaining
|
|
registered functions shall not be called and the rest of the <i>exit</i>() processing shall not be completed. If <i>exit</i>() is
|
|
called more than once, the behavior is undefined.</p>
|
|
|
|
<p>The <i>exit</i>() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove
|
|
all files created by <a href="../functions/tmpfile.html"><i>tmpfile</i>()</a>. Finally, control shall be terminated with the
|
|
consequences described below.</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> The
|
|
<i>_Exit</i>() and <i>_exit</i>() functions shall be functionally equivalent. <img src="../images/opt-end.gif" alt="[Option End]"
|
|
border="0"></p>
|
|
|
|
<p>The <i>_Exit</i>() <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt=
|
|
"[Option Start]" border="0"> and <i>_exit</i>() <img src="../images/opt-end.gif" alt="[Option End]" border="0"> functions
|
|
shall not call functions registered with <a href="../functions/atexit.html"><i>atexit</i>()</a> 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.</p>
|
|
|
|
<p>These functions shall terminate the calling process <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> with the following consequences: <img src="../images/opt-end.gif"
|
|
alt="[Option End]" border="0"> <basefont size="2"></p>
|
|
|
|
<dl>
|
|
<dt><b>Note:</b></dt>
|
|
|
|
<dd>These consequences are all extensions to the ISO C standard and are not further CX shaded. However, XSI extensions are
|
|
shaded.</dd>
|
|
</dl>
|
|
|
|
<basefont size="3">
|
|
|
|
<ul>
|
|
<li>
|
|
<p>All of the file descriptors, directory streams, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> conversion descriptors, and message catalog descriptors <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"> open in the calling process shall be closed.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If the parent process of the calling process is executing a <a href="../functions/wait.html"><i>wait</i>()</a> or <a href=
|
|
"../functions/waitpid.html"><i>waitpid</i>()</a>, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to
|
|
SIG_IGN, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> it shall be notified of the calling process' termination
|
|
and the low-order eight bits (that is, bits 0377) of <i>status</i> are made available to it. If the parent is not waiting, the
|
|
child's status shall be made available to it when the parent subsequently executes <a href=
|
|
"../functions/wait.html"><i>wait</i>()</a> or <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The semantics of the <a href="../functions/waitid.html"><i>waitid</i>()</a> function shall be equivalent to <a href=
|
|
"../functions/wait.html"><i>wait</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If the parent process of the calling process is not executing a <a href="../functions/wait.html"><i>wait</i>()</a> or <a href=
|
|
"../functions/waitpid.html"><i>waitpid</i>()</a>, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to
|
|
SIG_IGN, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> the calling process shall be transformed into a <i>zombie
|
|
process</i>. A <i>zombie process</i> is an inactive process and it shall be deleted at some later time when its parent process
|
|
executes <a href="../functions/wait.html"><i>wait</i>()</a> or <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The semantics of the <a href="../functions/waitid.html"><i>waitid</i>()</a> function shall be equivalent to <a href=
|
|
"../functions/wait.html"><i>wait</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly
|
|
terminates children in some circumstances.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Either:</p>
|
|
|
|
<p>If the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the parent process.</p>
|
|
|
|
<p>Or:</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
If the parent process has set its SA_NOCLDWAIT flag, or set SIGCHLD to SIG_IGN, the status shall be discarded, and the lifetime of
|
|
the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to
|
|
the parent process. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The parent process ID of all of the calling process' existing child processes and zombie processes shall be set to the process
|
|
ID of an implementation-defined system process. That is, these processes shall be inherited by a special system process.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Each attached shared-memory segment is detached and the value of <i>shm_nattch</i> (see <a href=
|
|
"../functions/shmget.html"><i>shmget</i>()</a>) in the data structure associated with its shared memory ID shall be decremented by
|
|
1. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
For each semaphore for which the calling process has set a <i>semadj</i> value (see <a href="semop.html"><i>semop</i>()</a> ), that
|
|
value shall be added to the <i>semval</i> of the specified semaphore. <img src="../images/opt-end.gif" alt="[Option End]" border=
|
|
"0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the
|
|
controlling terminal belonging to the calling process.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If the process is a controlling process, the controlling terminal associated with the session shall be disassociated from the
|
|
session, allowing it to be acquired by a new controlling process.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>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 SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly-orphaned process group.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('SEM')">SEM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
All open named semaphores in the calling process shall be closed as if by appropriate calls to <a href=
|
|
"../functions/sem_close.html"><i>sem_close</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('ML')">ML</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> Any
|
|
memory locks established by the process via calls to <a href="../functions/mlockall.html"><i>mlockall</i>()</a> or <a href=
|
|
"../functions/mlock.html"><i>mlock</i>()</a> shall be removed. If locked pages in the address space of the calling process are also
|
|
mapped into the address spaces of other processes and are locked by those processes, the locks established by the other processes
|
|
shall be unaffected by the call by this process to <i>_Exit</i>() or <i>_exit</i>(). <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('MF')">MF|SHM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Memory mappings that were created in the process shall be unmapped before the process is destroyed. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('TYM')">TYM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Any blocks of typed memory that were mapped in the calling process shall be unmapped, as if <a href=
|
|
"../functions/munmap.html"><i>munmap</i>()</a> was implicitly called to unmap them. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('MSG')">MSG</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
All open message queue descriptors in the calling process shall be closed as if by appropriate calls to <a href=
|
|
"../functions/mq_close.html"><i>mq_close</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('AIO')">AIO</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Any outstanding cancelable asynchronous I/O operations may be canceled. Those asynchronous I/O operations that are not canceled
|
|
shall complete as if the <i>_Exit</i>() or <i>_exit</i>() operation had not yet occurred, but any associated signal notifications
|
|
shall be suppressed. The <i>_Exit</i>() or <i>_exit</i>() operation may block awaiting such I/O completion. Whether any I/O is
|
|
canceled, and which I/O may be canceled upon <i>_Exit</i>() or <i>_exit</i>(), is implementation-defined. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Threads terminated by a call to <i>_Exit</i>() or <i>_exit</i>() shall not invoke their cancelation cleanup handlers or
|
|
per-thread data destructors.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('TRC')">TRC</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
If the calling process is a trace controller process, any trace streams that were created by the calling process shall be shut down
|
|
as described by the <a href="../functions/posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a> function, and any process'
|
|
mapping of trace event names to trace event type identifiers built for these trace streams may be deallocated. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
</ul>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_04"></a>RETURN VALUE</h4>
|
|
|
|
<blockquote>
|
|
<p>These functions do not return.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_05"></a>ERRORS</h4>
|
|
|
|
<blockquote>
|
|
<p>No errors are defined.</p>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<div class="box"><em>The following sections are informative.</em></div>
|
|
|
|
<h4><a name="tag_03_131_06"></a>EXAMPLES</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_07"></a>APPLICATION USAGE</h4>
|
|
|
|
<blockquote>
|
|
<p>Normally applications should use <i>exit</i>() rather than <i>_Exit</i>() or <i>_exit</i>().</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_08"></a>RATIONALE</h4>
|
|
|
|
<blockquote>
|
|
<h5><a name="tag_03_131_08_01"></a>Process Termination</h5>
|
|
|
|
<p>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: <i>normal termination</i> (as in the current specification), <i>simple abnormal termination</i>, and
|
|
<i>abnormal termination with actions</i>. 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.</p>
|
|
|
|
<p>The implementation-defined actions usually include, in most historical implementations, the creation of a file named <b>core</b>
|
|
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.</p>
|
|
|
|
<p>There is a potential security problem in creating a <b>core</b> 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
|
|
<b>core</b> file or should make it unreadable by the user.</p>
|
|
|
|
<p>Despite the silence of this volume of IEEE Std 1003.1-2001 on this feature, applications are advised not to create
|
|
files named <b>core</b> because of potential conflicts in many implementations. Some implementations use a name other than
|
|
<b>core</b> for the file; for example, by appending the process ID to the filename.</p>
|
|
|
|
<h5><a name="tag_03_131_08_02"></a>Terminating a Process</h5>
|
|
|
|
<p>It is important that the consequences of process termination as described occur regardless of whether the process called
|
|
<i>_exit</i>() (perhaps indirectly through <i>exit</i>()) or instead was terminated due to a signal or for some other reason. Note
|
|
that in the specific case of <i>exit</i>() this means that the <i>status</i> argument to <i>exit</i>() is treated in the same way
|
|
as the <i>status</i> argument to <i>_exit</i>().</p>
|
|
|
|
<p>A language other than C may have other termination primitives than the C-language <i>exit</i>() 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
|
|
<i>_exit</i>() 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.</p>
|
|
|
|
<p>As required by the ISO C standard, using <b>return</b> from <i>main</i>() has the same behavior (other than with respect to
|
|
language scope issues) as calling <i>exit</i>() with the returned value. Reaching the end of the <i>main</i>() function has the
|
|
same behavior as calling <i>exit</i>(0).</p>
|
|
|
|
<p>A value of zero (or EXIT_SUCCESS, which is required to be zero) for the argument <i>status</i> conventionally indicates
|
|
successful termination. This corresponds to the specification for <i>exit</i>() in the ISO C standard. The convention is
|
|
followed by utilities such as <a href="../utilities/make.html"><i>make</i></a> and various shells, which interpret a zero status
|
|
from a child process as success. For this reason, applications should not call <i>exit</i>(0) or <i>_exit</i>(0) when they
|
|
terminate unsuccessfully; for example, in signal-catching functions.</p>
|
|
|
|
<p>Historically, the implementation-defined process that inherits children whose parents have terminated without waiting on them is
|
|
called <i>init</i> and has a process ID of 1.</p>
|
|
|
|
<p>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 <i>vhangup</i>() 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 <i>_exit</i>() behave this way in such systems should not cause problems with existing
|
|
applications.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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
|
|
<i>_exit</i>() must consider processes other than child processes.</p>
|
|
|
|
<p>It is possible for a process group to be orphaned by a call to <a href="../functions/setpgid.html"><i>setpgid</i>()</a> or <a
|
|
href="../functions/setsid.html"><i>setsid</i>()</a>, 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 <a href=
|
|
"../basedefs/signal.h.html"><i><signal.h></i></a>.</p>
|
|
|
|
<p>The ISO/IEC 9899:1999 standard adds the <i>_Exit</i>() function that results in immediate program termination without
|
|
triggering signals or <a href="../functions/atexit.html"><i>atexit</i>()</a>-registered functions. In
|
|
IEEE Std 1003.1-2001, this is equivalent to the <i>_exit</i>() function.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_09"></a>FUTURE DIRECTIONS</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_10"></a>SEE ALSO</h4>
|
|
|
|
<blockquote>
|
|
<p><a href="atexit.html"><i>atexit</i>()</a> , <a href="close.html"><i>close</i>()</a> , <a href="fclose.html"><i>fclose</i>()</a>
|
|
, <a href="longjmp.html"><i>longjmp</i>()</a> , <a href="posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a> , <a href=
|
|
"posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a> , <a href="semop.html"><i>semop</i>()</a> , <a
|
|
href="shmget.html"><i>shmget</i>()</a> , <a href="sigaction.html"><i>sigaction</i>()</a> , <a href="wait.html"><i>wait</i>()</a> ,
|
|
<a href="waitid.html"><i>waitid</i>()</a> , <a href="waitpid.html"><i>waitpid</i>()</a> , the Base Definitions volume of
|
|
IEEE Std 1003.1-2001, <a href="../basedefs/stdlib.h.html"><i><stdlib.h></i></a>, <a href=
|
|
"../basedefs/unistd.h.html"><i><unistd.h></i></a></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_11"></a>CHANGE HISTORY</h4>
|
|
|
|
<blockquote>
|
|
<p>First released in Issue 1. Derived from Issue 1 of the SVID.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_12"></a>Issue 5</h4>
|
|
|
|
<blockquote>
|
|
<p>The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.</p>
|
|
|
|
<p>Interactions with the SA_NOCLDWAIT flag and SIGCHLD signal are further clarified.</p>
|
|
|
|
<p>The values of <i>status</i> from <i>exit</i>() are better described.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_131_13"></a>Issue 6</h4>
|
|
|
|
<blockquote>
|
|
<p>Extensions beyond the ISO C standard are marked.</p>
|
|
|
|
<p>The DESCRIPTION is updated for alignment with IEEE Std 1003.1j-2000 by adding semantics for typed memory.</p>
|
|
|
|
<p>The following changes are made for alignment with the ISO/IEC 9899:1999 standard:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>The <i>_Exit</i>() function is included.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The DESCRIPTION is updated.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The description of tracing semantics is added for alignment with IEEE Std 1003.1q-2000.</p>
|
|
|
|
<p>References to the <i>wait3</i>() function are removed.</p>
|
|
</blockquote>
|
|
|
|
<div class="box"><em>End of informative text.</em></div>
|
|
|
|
<hr>
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|