execv.html

IEEE 1003.1-2003, Single Unix Specification v3

array of pointers is noted as constant. The table of assignment compatibility for <i>dst</i>= <i>src</i> derived from the
ISO&nbsp;C standard summarizes the compatibility:</p>

<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th align="right">
<p class="tent"><i>dst</i>:</p>
</th>
<th align="left">
<p class="tent"><b>char *[]</b></p>
</th>
<th align="left">
<p class="tent"><b>const char *[]</b></p>
</th>
<th align="left">
<p class="tent"><b>char *const[]</b></p>
</th>
<th align="left">
<p class="tent"><b>const char *const[]</b></p>
</th>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><b><i>src</i>:</b></p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
<td align="center">
<p class="tent">&nbsp;</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><b>char *[]</b></p>
</td>
<td align="center">
<p class="tent">VALID</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">VALID</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><b>const char *[]</b></p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">VALID</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">VALID</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><b>char * const []</b></p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">VALID</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><b>const char *const[]</b></p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">-</p>
</td>
<td align="center">
<p class="tent">VALID</p>
</td>
</tr>
</table>
</center>

<p>Since all existing code has a source type matching the first row, the column that gives the most valid combinations is the third
column. The only other possibility is the fourth column, but using it would require a cast on the <i>argv</i> or <i>envp</i>
arguments. It is unfortunate that the fourth column cannot be used, because the declaration a non-expert would naturally use would
be that in the second row.</p>

<p>The ISO&nbsp;C standard and this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 do not conflict on the use of <i>environ</i>, but some
historical implementations of <i>environ</i> may cause a conflict. As long as <i>environ</i> is treated in the same way as an entry
point (for example, <a href="../functions/fork.html"><i>fork</i>()</a>), it conforms to both standards. A library can contain <a
href="../functions/fork.html"><i>fork</i>()</a>, but if there is a user-provided <a href=
"../functions/fork.html"><i>fork</i>()</a>, that <a href="../functions/fork.html"><i>fork</i>()</a> is given precedence and no
problem ensues. The situation is similar for <i>environ</i>: the definition in this volume of IEEE&nbsp;Std&nbsp;1003.1-2001 is to
be used if there is no user-provided <i>environ</i> to take precedence. At least three implementations are known to exist that
solve this problem.</p>

<dl compact>
<dt>[E2BIG]</dt>

<dd>The limit {ARG_MAX} applies not just to the size of the argument list, but to the sum of that and the size of the environment
list.</dd>

<dt>[EFAULT]</dt>

<dd>Some historical systems return [EFAULT] rather than [ENOEXEC] when the new process image file is corrupted. They are
non-conforming.</dd>

<dt>[EINVAL]</dt>

<dd>This error condition was added to IEEE&nbsp;Std&nbsp;1003.1-2001 to allow an implementation to detect executable files
generated for different architectures, and indicate this situation to the application. Historical implementations of shells,
<i>execvp</i>(), and <i>execlp</i>() that encounter an [ENOEXEC] error will execute a shell on the assumption that the file is a
shell script. This will not produce the desired effect when the file is a valid executable for a different architecture. An
implementation may now choose to avoid this problem by returning [EINVAL] when a valid executable for a different architecture is
encountered. Some historical implementations return [EINVAL] to indicate that the <i>path</i> argument contains a character with
the high order bit set. The standard developers chose to deviate from historical practice for the following reasons: 

<ol>
<li>
<p>The new utilization of [EINVAL] will provide some measure of utility to the user community.</p>
</li>

<li>
<p>Historical use of [EINVAL] is not acceptable in an internationalized operating environment.</p>
</li>
</ol>
</dd>

<dt>[ENAMETOOLONG]</dt>

<dd>
Since the file pathname may be constructed by taking elements in the <i>PATH</i> variable and putting them together with the
filename, the [ENAMETOOLONG] error condition could also be reached this way.</dd>

<dt>[ETXTBSY]</dt>

<dd>System V returns this error when the executable file is currently open for writing by some process. This volume of
IEEE&nbsp;Std&nbsp;1003.1-2001 neither requires nor prohibits this behavior.</dd>
</dl>

<p>Other systems (such as System V) may return [EINTR] from <i>exec</i>. This is not addressed by this volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, but implementations may have a window between the call to <i>exec</i> and the time that a signal
could cause one of the <i>exec</i> calls to return with [EINTR].</p>

<p>An explicit statement regarding the floating-point environment (as defined in the <a href=
"../basedefs/fenv.h.html"><i>&lt;fenv.h&gt;</i></a> header) was added to make it clear that the floating-point environment is set
to its default when a call to one of the <i>exec</i> functions succeeds. The requirements for inheritance or setting to the default
for other process and thread start-up functions is covered by more generic statements in their descriptions and can be summarized
as follows:</p>

<dl compact>
<dt><i>posix_spawn</i>()</dt>

<dd>Set to default.</dd>

<dt><i>fork</i>()</dt>

<dd>Inherit.</dd>

<dt><i>pthread_create</i>()</dt>

<dd>Inherit.</dd>
</dl>
</blockquote>

<h4><a name="tag_03_130_09"></a>FUTURE DIRECTIONS</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_130_10"></a>SEE ALSO</h4>

<blockquote>
<p><a href="alarm.html"><i>alarm</i>()</a> , <a href="atexit.html"><i>atexit</i>()</a> , <a href="chmod.html"><i>chmod</i>()</a> ,
<a href="close.html"><i>close</i>()</a> , <a href="exit.html"><i>exit</i>()</a> , <a href="fcntl.html"><i>fcntl</i>()</a> , <a
href="fork.html"><i>fork</i>()</a> , <a href="fstatvfs.html"><i>fstatvfs</i>()</a> , <a href="getenv.html"><i>getenv</i>()</a> , <a
href="getitimer.html"><i>getitimer</i>()</a> , <a href="getrlimit.html"><i>getrlimit</i>()</a> , <a href=
"mmap.html"><i>mmap</i>()</a> , <a href="nice.html"><i>nice</i>()</a> , <a href="posix_spawn.html"><i>posix_spawn</i>()</a> , <a
href="posix_trace_eventid_open.html"><i>posix_trace_eventid_open</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="putenv.html"><i>putenv</i>()</a> , <a
href="semop.html"><i>semop</i>()</a> , <a href="setlocale.html"><i>setlocale</i>()</a> , <a href="shmat.html"><i>shmat</i>()</a> ,
<a href="sigaction.html"><i>sigaction</i>()</a> , <a href="sigaltstack.html"><i>sigaltstack</i>()</a> , <a href=
"sigpending.html"><i>sigpending</i>()</a> , <a href="sigprocmask.html"><i>sigprocmask</i>()</a> , <a href=
"system.html"><i>system</i>()</a> , <a href="times.html"><i>times</i>()</a> , <a href="ulimit.html"><i>ulimit</i>()</a> , <a href=
"umask.html"><i>umask</i>()</a> , the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/xbd_chap11.html#tag_11">Chapter 11, General Terminal Interface</a>, <a href=
"../basedefs/unistd.h.html"><i>&lt;unistd.h&gt;</i></a></p>
</blockquote>

<h4><a name="tag_03_130_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_130_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>Large File Summit extensions are added.</p>
</blockquote>

<h4><a name="tag_03_130_13"></a>Issue 6</h4>

<blockquote>
<p>The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:</p>

<ul>
<li>
<p>In the DESCRIPTION, behavior is defined for when the process image file is not a valid executable.</p>
</li>

<li>
<p>In this issue, _POSIX_SAVED_IDS is mandated, thus the effective user ID and effective group ID of the new process image shall be
saved (as the saved set-user-ID and the saved set-group-ID) for use by the <a href="../functions/setuid.html"><i>setuid</i>()</a>
function.</p>
</li>

<li>
<p>The [ELOOP] mandatory error condition is added.</p>
</li>

<li>
<p>A second [ENAMETOOLONG] is added as an optional error condition.</p>
</li>

<li>
<p>The [ETXTBSY] optional error condition is added.</p>
</li>
</ul>

<p>The following changes were made to align with the IEEE&nbsp;P1003.1a draft standard:</p>

<ul>
<li>
<p>The [EINVAL] mandatory error condition is added.</p>
</li>

<li>
<p>The [ELOOP] optional error condition is added.</p>
</li>
</ul>

<p>The description of CPU-time clock semantics is added for alignment with IEEE&nbsp;Std&nbsp;1003.1d-1999.</p>

<p>The DESCRIPTION is updated for alignment with IEEE&nbsp;Std&nbsp;1003.1j-2000 by adding semantics for typed memory.</p>

<p>The DESCRIPTION is updated to avoid use of the term &quot;must&quot; for application requirements.</p>

<p>The description of tracing semantics is added for alignment with IEEE&nbsp;Std&nbsp;1003.1q-2000.</p>

<p>IEEE PASC Interpretation 1003.1 #132 is applied.</p>

<p>The DESCRIPTION is updated to make it explicit that the floating-point environment in the new process image is set to the
default.</p>

<p>The DESCRIPTION and RATIONALE are updated to include clarifications of how the contents of a process image file affect the
behavior of the <i>exec</i> functions.</p>

<p>IEEE&nbsp;Std 1003.1-2001/Cor&nbsp;1-2002, item XSH/TC1/D6/15 is applied, adding a new paragraph to the DESCRIPTION and text to
the end of the APPLICATION USAGE section. This change addresses a security concern, where implementations may want to reopen file
descriptors 0, 1, and 2 for programs with the set-user-id or set-group-id file mode bits calling the <i>exec</i> family of
functions.</p>
</blockquote>

<div class="box"><em>End of informative text.</em></div>

<hr>
<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; 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>