Mercurial > repo

comparison _exit.html @ 7330:0eae4b049f93

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
<oerjan> fetch http://pubs.opengroup.org/onlinepubs/009695399/functions/_exit.html
author HackBot
date Thu, 31 Mar 2016 09:29:40 +0000
parents
children
comparison
equal deleted inserted replaced
7329:a8fd9da10348 7330:0eae4b049f93
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html>
3 <head>
4 <meta name="generator" content="HTML Tidy, see www.w3.org">
5 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
6 <link type="text/css" rel="stylesheet" href="style.css">
7 <!-- Generated by The Open Group's rhtm tool v1.2.1 -->
8 <!-- Copyright (c) 2001-2004 IEEE and The Open Group, All Rights Reserved -->
9 <title>exit</title>
10 </head>
11 <body bgcolor="white">
12 <script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
13 </script>
14
15 <basefont size="3"> <a name="exit"></a> <a name="tag_03_131"></a><!-- exit -->
16 <!--header start-->
17 <center><font size="2">The Open Group Base Specifications Issue 6<br>
18 IEEE Std 1003.1, 2004 Edition<br>
19 Copyright &copy; 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>
20
21 <!--header end-->
22 <hr size="2" noshade>
23 <h4><a name="tag_03_131_01"></a>NAME</h4>
24
25 <blockquote>exit, _Exit, _exit - terminate a process</blockquote>
26
27 <h4><a name="tag_03_131_02"></a>SYNOPSIS</h4>
28
29 <blockquote class="synopsis">
30 <p><code><tt>#include &lt;<a href="../basedefs/stdlib.h.html">stdlib.h</a>&gt;<br>
31 <br>
32 void exit(int</tt> <i>status</i><tt>);<br>
33 void _Exit(int</tt> <i>status</i><tt>);<br>
34 <br>
35 <br>
36 #include &lt;<a href="../basedefs/unistd.h.html">unistd.h</a>&gt;<br>
37 void _exit(int</tt> <i>status</i><tt>);<br>
38 </tt></code></p>
39 </blockquote>
40
41 <h4><a name="tag_03_131_03"></a>DESCRIPTION</h4>
42
43 <blockquote>
44 <p>For <i>exit</i>() and <i>_Exit</i>(): <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src=
45 "../images/opt-start.gif" alt="[Option Start]" border="0"> The functionality described on this reference page is aligned with the
46 ISO&nbsp;C standard. Any conflict between the requirements described here and the ISO&nbsp;C standard is unintentional. This volume
47 of IEEE&nbsp;Std&nbsp;1003.1-2001 defers to the ISO&nbsp;C standard. <img src="../images/opt-end.gif" alt="[Option End]" border=
48 "0"></p>
49
50 <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
51 src="../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;or any other value, though only the least significant 8 bits
52 (that is, <i>status</i> &amp; 0377) shall be available to a waiting parent process. <img src="../images/opt-end.gif" alt=
53 "[Option End]" border="0"></p>
54
55 <p>The <i>exit</i>() function shall first call all functions registered by <a href="../functions/atexit.html"><i>atexit</i>()</a>,
56 in the reverse order of their registration, except that a function is called after any previously registered functions that had
57 already been called at the time it was registered. Each function is called as many times as it was registered. If, during the call
58 to any such function, a call to the <a href="../functions/longjmp.html"><i>longjmp</i>()</a> function is made that would terminate
59 the call to the registered function, the behavior is undefined.</p>
60
61 <p>If a function registered by a call to <a href="../functions/atexit.html"><i>atexit</i>()</a> fails to return, the remaining
62 registered functions shall not be called and the rest of the <i>exit</i>() processing shall not be completed. If <i>exit</i>() is
63 called more than once, the behavior is undefined.</p>
64
65 <p>The <i>exit</i>() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove
66 all files created by <a href="../functions/tmpfile.html"><i>tmpfile</i>()</a>. Finally, control shall be terminated with the
67 consequences described below.</p>
68
69 <p><sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> The
70 <i>_Exit</i>() and <i>_exit</i>() functions shall be functionally equivalent. <img src="../images/opt-end.gif" alt="[Option End]"
71 border="0"></p>
72
73 <p>The <i>_Exit</i>() <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt=
74 "[Option Start]" border="0"> &nbsp;and <i>_exit</i>() <img src="../images/opt-end.gif" alt="[Option End]" border="0"> functions
75 shall not call functions registered with <a href="../functions/atexit.html"><i>atexit</i>()</a> nor any registered signal handlers.
76 Whether open streams are flushed or closed, or temporary files are removed is implementation-defined. Finally, the calling process
77 is terminated with the consequences described below.</p>
78
79 <p>These functions shall terminate the calling process <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src=
80 "../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;with the following consequences: <img src="../images/opt-end.gif"
81 alt="[Option End]" border="0"> <basefont size="2"></p>
82
83 <dl>
84 <dt><b>Note:</b></dt>
85
86 <dd>These consequences are all extensions to the ISO&nbsp;C standard and are not further CX shaded. However, XSI extensions are
87 shaded.</dd>
88 </dl>
89
90 <basefont size="3">
91
92 <ul>
93 <li>
94 <p>All of the file descriptors, directory streams, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src=
95 "../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;conversion descriptors, and message catalog descriptors <img src=
96 "../images/opt-end.gif" alt="[Option End]" border="0"> &nbsp;open in the calling process shall be closed.</p>
97 </li>
98
99 <li>
100 <p>If the parent process of the calling process is executing a <a href="../functions/wait.html"><i>wait</i>()</a> or <a href=
101 "../functions/waitpid.html"><i>waitpid</i>()</a>, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src=
102 "../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to
103 SIG_IGN, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> it shall be notified of the calling process' termination
104 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
105 child's status shall be made available to it when the parent subsequently executes <a href=
106 "../functions/wait.html"><i>wait</i>()</a> or <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p>
107
108 <p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
109 The semantics of the <a href="../functions/waitid.html"><i>waitid</i>()</a> function shall be equivalent to <a href=
110 "../functions/wait.html"><i>wait</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
111 </li>
112
113 <li>
114 <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=
115 "../functions/waitpid.html"><i>waitpid</i>()</a>, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src=
116 "../images/opt-start.gif" alt="[Option Start]" border="0"> &nbsp;and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to
117 SIG_IGN, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> the calling process shall be transformed into a <i>zombie
118 process</i>. A <i>zombie process</i> is an inactive process and it shall be deleted at some later time when its parent process
119 executes <a href="../functions/wait.html"><i>wait</i>()</a> or <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p>
120
121 <p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
122 The semantics of the <a href="../functions/waitid.html"><i>waitid</i>()</a> function shall be equivalent to <a href=
123 "../functions/wait.html"><i>wait</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
124 </li>
125
126 <li>
127 <p>Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly
128 terminates children in some circumstances.</p>
129 </li>
130
131 <li>
132 <p>Either:</p>
133
134 <p>If the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the parent process.</p>
135
136 <p>Or:</p>
137
138 <p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
139 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
140 the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to
141 the parent process. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
142 </li>
143
144 <li>
145 <p>The parent process ID of all of the calling process' existing child processes and zombie processes shall be set to the process
146 ID of an implementation-defined system process. That is, these processes shall be inherited by a special system process.</p>
147 </li>
148
149 <li>
150 <p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
151 Each attached shared-memory segment is detached and the value of <i>shm_nattch</i> (see <a href=
152 "../functions/shmget.html"><i>shmget</i>()</a>) in the data structure associated with its shared memory ID shall be decremented by
153 1. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
154 </li>
155
156 <li>
157 <p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
158 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
159 value shall be added to the <i>semval</i> of the specified semaphore. <img src="../images/opt-end.gif" alt="[Option End]" border=
160 "0"></p>
161 </li>
162
163 <li>
164 <p>If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the
165 controlling terminal belonging to the calling process.</p>
166 </li>
167
168 <li>
169 <p>If the process is a controlling process, the controlling terminal associated with the session shall be disassociated from the
170 session, allowing it to be acquired by a new controlling process.</p>
171 </li>
172
173 <li>
174 <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
175 stopped, then a SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly-orphaned process group.</p>
176 </li>
177
178 <li>
179 <p><sup>[<a href="javascript:open_code('SEM')">SEM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
180 All open named semaphores in the calling process shall be closed as if by appropriate calls to <a href=
181 "../functions/sem_close.html"><i>sem_close</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
182 </li>
183
184 <li>
185 <p><sup>[<a href="javascript:open_code('ML')">ML</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> Any
186 memory locks established by the process via calls to <a href="../functions/mlockall.html"><i>mlockall</i>()</a> or <a href=
187 "../functions/mlock.html"><i>mlock</i>()</a> shall be removed. If locked pages in the address space of the calling process are also
188 mapped into the address spaces of other processes and are locked by those processes, the locks established by the other processes
189 shall be unaffected by the call by this process to <i>_Exit</i>() or <i>_exit</i>(). <img src="../images/opt-end.gif" alt=
190 "[Option End]" border="0"></p>
191 </li>
192
193 <li>
194 <p><sup>[<a href="javascript:open_code('MF')">MF|SHM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
195 Memory mappings that were created in the process shall be unmapped before the process is destroyed. <img src=
196 "../images/opt-end.gif" alt="[Option End]" border="0"></p>
197 </li>
198
199 <li>
200 <p><sup>[<a href="javascript:open_code('TYM')">TYM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
201 Any blocks of typed memory that were mapped in the calling process shall be unmapped, as if <a href=
202 "../functions/munmap.html"><i>munmap</i>()</a> was implicitly called to unmap them. <img src="../images/opt-end.gif" alt=
203 "[Option End]" border="0"></p>
204 </li>
205
206 <li>
207 <p><sup>[<a href="javascript:open_code('MSG')">MSG</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
208 All open message queue descriptors in the calling process shall be closed as if by appropriate calls to <a href=
209 "../functions/mq_close.html"><i>mq_close</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
210 </li>
211
212 <li>
213 <p><sup>[<a href="javascript:open_code('AIO')">AIO</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
214 Any outstanding cancelable asynchronous I/O operations may be canceled. Those asynchronous I/O operations that are not canceled
215 shall complete as if the <i>_Exit</i>() or <i>_exit</i>() operation had not yet occurred, but any associated signal notifications
216 shall be suppressed. The <i>_Exit</i>() or <i>_exit</i>() operation may block awaiting such I/O completion. Whether any I/O is
217 canceled, and which I/O may be canceled upon <i>_Exit</i>() or <i>_exit</i>(), is implementation-defined. <img src=
218 "../images/opt-end.gif" alt="[Option End]" border="0"></p>
219 </li>
220
221 <li>
222 <p>Threads terminated by a call to <i>_Exit</i>() or <i>_exit</i>() shall not invoke their cancellation cleanup handlers or
223 per-thread data destructors.</p>
224 </li>
225
226 <li>
227 <p><sup>[<a href="javascript:open_code('TRC')">TRC</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
228 If the calling process is a trace controller process, any trace streams that were created by the calling process shall be shut down
229 as described by the <a href="../functions/posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a> function, and any process'
230 mapping of trace event names to trace event type identifiers built for these trace streams may be deallocated. <img src=
231 "../images/opt-end.gif" alt="[Option End]" border="0"></p>
232 </li>
233 </ul>
234 </blockquote>
235
236 <h4><a name="tag_03_131_04"></a>RETURN VALUE</h4>
237
238 <blockquote>
239 <p>These functions do not return.</p>
240 </blockquote>
241
242 <h4><a name="tag_03_131_05"></a>ERRORS</h4>
243
244 <blockquote>
245 <p>No errors are defined.</p>
246 </blockquote>
247
248 <hr>
249 <div class="box"><em>The following sections are informative.</em></div>
250
251 <h4><a name="tag_03_131_06"></a>EXAMPLES</h4>
252
253 <blockquote>
254 <p>None.</p>
255 </blockquote>
256
257 <h4><a name="tag_03_131_07"></a>APPLICATION USAGE</h4>
258
259 <blockquote>
260 <p>Normally applications should use <i>exit</i>() rather than <i>_Exit</i>() or <i>_exit</i>().</p>
261 </blockquote>
262
263 <h4><a name="tag_03_131_08"></a>RATIONALE</h4>
264
265 <blockquote>
266 <h5><a name="tag_03_131_08_01"></a>Process Termination</h5>
267
268 <p>Early proposals drew a distinction between normal and abnormal process termination. Abnormal termination was caused only by
269 certain signals and resulted in implementation-defined &quot;actions&quot;, as discussed below. Subsequent proposals distinguished three
270 types of termination: <i>normal termination</i> (as in the current specification), <i>simple abnormal termination</i>, and
271 <i>abnormal termination with actions</i>. Again the distinction between the two types of abnormal termination was that they were
272 caused by different signals and that implementation-defined actions would result in the latter case. Given that these actions were
273 completely implementation-defined, the early proposals were only saying when the actions could occur and how their occurrence could
274 be detected, but not what they were. This was of little or no use to conforming applications, and thus the distinction is not made
275 in this volume of IEEE&nbsp;Std&nbsp;1003.1-2001.</p>
276
277 <p>The implementation-defined actions usually include, in most historical implementations, the creation of a file named <b>core</b>
278 in the current working directory of the process. This file contains an image of the memory of the process, together with
279 descriptive information about the process, perhaps sufficient to reconstruct the state of the process at the receipt of the
280 signal.</p>
281
282 <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
283 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
284 user does not have permission to write in the current directory. In this situation, an implementation either should not create a
285 <b>core</b> file or should make it unreadable by the user.</p>
286
287 <p>Despite the silence of this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 on this feature, applications are advised not to create
288 files named <b>core</b> because of potential conflicts in many implementations. Some implementations use a name other than
289 <b>core</b> for the file; for example, by appending the process ID to the filename.</p>
290
291 <h5><a name="tag_03_131_08_02"></a>Terminating a Process</h5>
292
293 <p>It is important that the consequences of process termination as described occur regardless of whether the process called
294 <i>_exit</i>() (perhaps indirectly through <i>exit</i>()) or instead was terminated due to a signal or for some other reason. Note
295 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
296 as the <i>status</i> argument to <i>_exit</i>().</p>
297
298 <p>A language other than C may have other termination primitives than the C-language <i>exit</i>() function, and programs written
299 in such a language should use its native termination primitives, but those should have as part of their function the behavior of
300 <i>_exit</i>() as described. Implementations in languages other than C are outside the scope of this version of this volume of
301 IEEE&nbsp;Std&nbsp;1003.1-2001, however.</p>
302
303 <p>As required by the ISO&nbsp;C standard, using <b>return</b> from <i>main</i>() has the same behavior (other than with respect to
304 language scope issues) as calling <i>exit</i>() with the returned value. Reaching the end of the <i>main</i>() function has the
305 same behavior as calling <i>exit</i>(0).</p>
306
307 <p>A value of zero (or EXIT_SUCCESS, which is required to be zero) for the argument <i>status</i> conventionally indicates
308 successful termination. This corresponds to the specification for <i>exit</i>() in the ISO&nbsp;C standard. The convention is
309 followed by utilities such as <a href="../utilities/make.html"><i>make</i></a> and various shells, which interpret a zero status
310 from a child process as success. For this reason, applications should not call <i>exit</i>(0) or <i>_exit</i>(0) when they
311 terminate unsuccessfully; for example, in signal-catching functions.</p>
312
313 <p>Historically, the implementation-defined process that inherits children whose parents have terminated without waiting on them is
314 called <i>init</i> and has a process ID of 1.</p>
315
316 <p>The sending of a SIGHUP to the foreground process group when a controlling process terminates corresponds to somewhat different
317 historical implementations. In System V, the kernel sends a SIGHUP on termination of (essentially) a controlling process. In 4.2
318 BSD, the kernel does not send SIGHUP in a case like this, but the termination of a controlling process is usually noticed by a
319 system daemon, which arranges to send a SIGHUP to the foreground process group with the <i>vhangup</i>() function. However, in 4.2
320 BSD, due to the behavior of the shells that support job control, the controlling process is usually a shell with no other processes
321 in its process group. Thus, a change to make <i>_exit</i>() behave this way in such systems should not cause problems with existing
322 applications.</p>
323
324 <p>The termination of a process may cause a process group to become orphaned in either of two ways. The connection of a process
325 group to its parent(s) outside of the group depends on both the parents and their children. Thus, a process group may be orphaned
326 by the termination of the last connecting parent process outside of the group or by the termination of the last direct descendant
327 of the parent process(es). In either case, if the termination of a process causes a process group to become orphaned, processes
328 within the group are disconnected from their job control shell, which no longer has any information on the existence of the process
329 group. Stopped processes within the group would languish forever. In order to avoid this problem, newly orphaned process groups
330 that contain stopped processes are sent a SIGHUP signal and a SIGCONT signal to indicate that they have been disconnected from
331 their session. The SIGHUP signal causes the process group members to terminate unless they are catching or ignoring SIGHUP. Under
332 most circumstances, all of the members of the process group are stopped if any of them are stopped.</p>
333
334 <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
335 BSD, which sends SIGHUP and SIGCONT to each stopped child of an exiting process. If such children exit in response to the SIGHUP,
336 any additional descendants receive similar treatment at that time. In this volume of IEEE&nbsp;Std&nbsp;1003.1-2001, the signals
337 are sent to the entire process group at the same time. Also, in this volume of IEEE&nbsp;Std&nbsp;1003.1-2001, but not in 4.2 BSD,
338 stopped processes may be orphaned, but may be members of a process group that is not orphaned; therefore, the action taken at
339 <i>_exit</i>() must consider processes other than child processes.</p>
340
341 <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
342 href="../functions/setsid.html"><i>setsid</i>()</a>, as well as by process termination. This volume of
343 IEEE&nbsp;Std&nbsp;1003.1-2001 does not require sending SIGHUP and SIGCONT in those cases, because, unlike process termination,
344 those cases are not caused accidentally by applications that are unaware of job control. An implementation can choose to send
345 SIGHUP and SIGCONT in those cases as an extension; such an extension must be documented as required in <a href=
346 "../basedefs/signal.h.html"><i>&lt;signal.h&gt;</i></a>.</p>
347
348 <p>The ISO/IEC&nbsp;9899:1999 standard adds the <i>_Exit</i>() function that results in immediate program termination without
349 triggering signals or <a href="../functions/atexit.html"><i>atexit</i>()</a>-registered functions. In
350 IEEE&nbsp;Std&nbsp;1003.1-2001, this is equivalent to the <i>_exit</i>() function.</p>
351 </blockquote>
352
353 <h4><a name="tag_03_131_09"></a>FUTURE DIRECTIONS</h4>
354
355 <blockquote>
356 <p>None.</p>
357 </blockquote>
358
359 <h4><a name="tag_03_131_10"></a>SEE ALSO</h4>
360
361 <blockquote>
362 <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>
363 , <a href="longjmp.html"><i>longjmp</i>()</a>, <a href="posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a>, <a href=
364 "posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a>, <a href="semop.html"><i>semop</i>()</a>, <a
365 href="shmget.html"><i>shmget</i>()</a>, <a href="sigaction.html"><i>sigaction</i>()</a>, <a href="wait.html"><i>wait</i>()</a>,
366 <a href="waitid.html"><i>waitid</i>()</a>, <a href="waitpid.html"><i>waitpid</i>()</a>, the Base Definitions volume of
367 IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/stdlib.h.html"><i>&lt;stdlib.h&gt;</i></a>, <a href=
368 "../basedefs/unistd.h.html"><i>&lt;unistd.h&gt;</i></a></p>
369 </blockquote>
370
371 <h4><a name="tag_03_131_11"></a>CHANGE HISTORY</h4>
372
373 <blockquote>
374 <p>First released in Issue 1. Derived from Issue 1 of the SVID.</p>
375 </blockquote>
376
377 <h4><a name="tag_03_131_12"></a>Issue 5</h4>
378
379 <blockquote>
380 <p>The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.</p>
381
382 <p>Interactions with the SA_NOCLDWAIT flag and SIGCHLD signal are further clarified.</p>
383
384 <p>The values of <i>status</i> from <i>exit</i>() are better described.</p>
385 </blockquote>
386
387 <h4><a name="tag_03_131_13"></a>Issue 6</h4>
388
389 <blockquote>
390 <p>Extensions beyond the ISO&nbsp;C standard are marked.</p>
391
392 <p>The DESCRIPTION is updated for alignment with IEEE&nbsp;Std&nbsp;1003.1j-2000 by adding semantics for typed memory.</p>
393
394 <p>The following changes are made for alignment with the ISO/IEC&nbsp;9899:1999 standard:</p>
395
396 <ul>
397 <li>
398 <p>The <i>_Exit</i>() function is included.</p>
399 </li>
400
401 <li>
402 <p>The DESCRIPTION is updated.</p>
403 </li>
404 </ul>
405
406 <p>The description of tracing semantics is added for alignment with IEEE&nbsp;Std&nbsp;1003.1q-2000.</p>
407
408 <p>References to the <i>wait3</i>() function are removed.</p>
409
410 <p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/16 is applied, correcting grammar in the DESCRIPTION.</p>
411 </blockquote>
412
413 <div class="box"><em>End of informative text.</em></div>
414
415 <hr size="2" noshade>
416 <center><font size="2"><!--footer start-->
417 UNIX &reg; is a registered Trademark of The Open Group.<br>
418 POSIX &reg; is a registered Trademark of The IEEE.<br>
419 [ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
420 "../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
421 ]</font></center>
422
423 <!--footer end-->
424 <hr size="2" noshade>
425 </body>
426 </html>
427