Mercurial > repo
changeset 7332:50781dbe0bdb
<oerjan> ` rm -v _?xit.html
author | HackBot |
---|---|
date | Thu, 31 Mar 2016 09:30:45 +0000 |
parents | 84581528a29e |
children | 93510317741b |
files | _Exit.html _exit.html |
diffstat | 2 files changed, 0 insertions(+), 854 deletions(-) [+] |
line wrap: on
line diff
--- a/_Exit.html Thu Mar 31 09:29:50 2016 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,427 +0,0 @@ -<!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-2004 IEEE and 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, 2004 Edition<br> -Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.</font></center><center><font color="red">A newer edition of this document exists <a href="http://pubs.opengroup.org/onlinepubs/9699919799/" target="_parent">here</a></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> shall be 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 cancellation 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> - -<p>IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/16 is applied, correcting grammar in the DESCRIPTION.</p> -</blockquote> - -<div class="box"><em>End of informative text.</em></div> - -<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> -
--- a/_exit.html Thu Mar 31 09:29:50 2016 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,427 +0,0 @@ -<!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-2004 IEEE and 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, 2004 Edition<br> -Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.</font></center><center><font color="red">A newer edition of this document exists <a href="http://pubs.opengroup.org/onlinepubs/9699919799/" target="_parent">here</a></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> shall be 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 cancellation 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> - -<p>IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/16 is applied, correcting grammar in the DESCRIPTION.</p> -</blockquote> - -<div class="box"><em>End of informative text.</em></div> - -<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> -