Mercurial > repo
comparison _Exit.html @ 7331:84581528a29e
<oerjan> fetch http://pubs.opengroup.org/onlinepubs/009695399/functions/_Exit.html
author | HackBot |
---|---|
date | Thu, 31 Mar 2016 09:29:50 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
7330:0eae4b049f93 | 7331:84581528a29e |
---|---|
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 © 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 <<a href="../basedefs/stdlib.h.html">stdlib.h</a>><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 <<a href="../basedefs/unistd.h.html">unistd.h</a>><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 C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume | |
47 of IEEE Std 1003.1-2001 defers to the ISO 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"> or any other value, though only the least significant 8 bits | |
52 (that is, <i>status</i> & 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"> 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"> 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 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"> conversion descriptors, and message catalog descriptors <img src= | |
96 "../images/opt-end.gif" alt="[Option End]" border="0"> 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"> 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"> 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 "actions", 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 Std 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 Std 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 Std 1003.1-2001, however.</p> | |
302 | |
303 <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 | |
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 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 Std 1003.1-2001, the signals | |
337 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, | |
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 Std 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><signal.h></i></a>.</p> | |
347 | |
348 <p>The ISO/IEC 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 Std 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 Std 1003.1-2001, <a href="../basedefs/stdlib.h.html"><i><stdlib.h></i></a>, <a href= | |
368 "../basedefs/unistd.h.html"><i><unistd.h></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 C standard are marked.</p> | |
391 | |
392 <p>The DESCRIPTION is updated for alignment with IEEE Std 1003.1j-2000 by adding semantics for typed memory.</p> | |
393 | |
394 <p>The following changes are made for alignment with the ISO/IEC 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 Std 1003.1q-2000.</p> | |
407 | |
408 <p>References to the <i>wait3</i>() function are removed.</p> | |
409 | |
410 <p>IEEE Std 1003.1-2001/Cor 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 ® is a registered Trademark of The Open Group.<br> | |
418 POSIX ® 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 |