📄 xsh_chap02_05.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta name="generator" content="HTML Tidy, see www.w3.org"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 --><!-- Copyright (c) 2001-2004 IEEE and The Open Group, All Rights Reserved --><title>System Interfaces Chapter 2</title></head><body><script type="text/javascript" language="JavaScript" src="../jscript/codes.js"></script><basefont size="3"> <center><font size="2">The Open Group Base Specifications Issue 6<br>IEEE Std 1003.1, 2004 Edition</font></center><hr size="2" noshade><h3><a name="tag_02_05"> 2.5 </a>Standard I/O Streams</h3><p>A stream is associated with an external file (which may be a physical device) by ``opening'' a file, which may involve``creating'' a new file. Creating an existing file causes its former contents to be discarded if necessary. If a file can supportpositioning requests (such as a disk file, as opposed to a terminal), then a ``file position indicator'' associated with the streamis positioned at the start (byte number 0) of the file, unless the file is opened with append mode, in which case it isimplementation-defined whether the file position indicator is initially positioned at the beginning or end of the file. The fileposition indicator is maintained by subsequent reads, writes, and positioning requests, to facilitate an orderly progressionthrough the file. All input takes place as if bytes were read by successive calls to <a href="../functions/fgetc.html"><i>fgetc</i>()</a>; all output takes place as if bytes were written by successive calls to <a href="../functions/fputc.html"><i>fputc</i>()</a>.</p><p>When a stream is ``unbuffered'', bytes are intended to appear from the source or at the destination as soon as possible;otherwise, bytes may be accumulated and transmitted as a block. When a stream is ``fully buffered'', bytes are intended to betransmitted as a block when a buffer is filled. When a stream is ``line buffered'', bytes are intended to be transmitted as a blockwhen a newline byte is encountered. Furthermore, bytes are intended to be transmitted as a block when a buffer is filled, wheninput is requested on an unbuffered stream, or when input is requested on a line-buffered stream that requires the transmission ofbytes. Support for these characteristics is implementation-defined, and may be affected via <a href="../functions/setbuf.html"><i>setbuf</i>()</a> and <a href="../functions/setvbuf.html"><i>setvbuf</i>()</a>.</p><p>A file may be disassociated from a controlling stream by ``closing'' the file. Output streams are flushed (any unwritten buffercontents are transmitted) before the stream is disassociated from the file. The value of a pointer to a <b>FILE</b> object isunspecified after the associated file is closed (including the standard streams).</p><p>A file may be subsequently reopened, by the same or another program execution, and its contents reclaimed or modified (if it canbe repositioned at its start). If the <i>main</i>() function returns to its original caller, or if the <a href="../functions/exit.html"><i>exit</i>()</a> function is called, all open files are closed (hence all output streams are flushed)before program termination. Other paths to program termination, such as calling <a href="../functions/abort.html"><i>abort</i>()</a>, need not close all files properly.</p><p>The address of the <b>FILE</b> object used to control a stream may be significant; a copy of a <b>FILE</b> object need notnecessarily serve in place of the original.</p><p>At program start-up, three streams are predefined and need not be opened explicitly: <i>standard input</i> (for readingconventional input), <i>standard output</i> (for writing conventional output), and <i>standard error</i> (for writing diagnosticoutput). When opened, the standard error stream is not fully buffered; the standard input and standard output streams are fullybuffered if and only if the stream can be determined not to refer to an interactive device.</p><h4><a name="tag_02_05_01"> 2.5.1 </a>Interaction of File Descriptors and Standard I/O Streams</h4><p><sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">This section describes the interaction of file descriptors and standard I/O streams. This functionality is an extension to theISO C standard (and the rest of this section is not further CX shaded). <img src="../images/opt-end.gif" alt="[Option End]"border="0"></p><p>An open file description may be accessed through a file descriptor, which is created using functions such as <a href="../functions/open.html"><i>open</i>()</a> or <a href="../functions/pipe.html"><i>pipe</i>()</a>, or through a stream, which iscreated using functions such as <a href="../functions/fopen.html"><i>fopen</i>()</a> or <a href="../functions/popen.html"><i>popen</i>()</a>. Either a file descriptor or a stream is called a ``handle'' on the open filedescription to which it refers; an open file description may have several handles.</p><p>Handles can be created or destroyed by explicit user action, without affecting the underlying open file description. Some of theways to create them include <a href="../functions/fcntl.html"><i>fcntl</i>()</a>, <a href="../functions/dup.html"><i>dup</i>()</a>,<a href="../functions/fdopen.html"><i>fdopen</i>()</a>, <a href="../functions/fileno.html"><i>fileno</i>()</a>, and <a href="../functions/fork.html"><i>fork</i>()</a>. They can be destroyed by at least <a href="../functions/fclose.html"><i>fclose</i>()</a>, <a href="../functions/close.html"><i>close</i>()</a>, and the <i><a href="../functions/exec.html">exec</a></i> functions.</p><p>A file descriptor that is never used in an operation that could affect the file offset (for example, <a href="../functions/read.html"><i>read</i>()</a>, <a href="../functions/write.html"><i>write</i>()</a>, or <a href="../functions/lseek.html"><i>lseek</i>()</a>) is not considered a handle for this discussion, but could give rise to one (forexample, as a consequence of <a href="../functions/fdopen.html"><i>fdopen</i>()</a>, <a href="../functions/dup.html"><i>dup</i>()</a>, or <a href="../functions/fork.html"><i>fork</i>()</a>). This exception does not includethe file descriptor underlying a stream, whether created with <a href="../functions/fopen.html"><i>fopen</i>()</a> or <a href="../functions/fdopen.html"><i>fdopen</i>()</a>, so long as it is not used directly by the application to affect the file offset.The <a href="../functions/read.html"><i>read</i>()</a> and <a href="../functions/write.html"><i>write</i>()</a> functionsimplicitly affect the file offset; <a href="../functions/lseek.html"><i>lseek</i>()</a> explicitly affects it.</p><p>The result of function calls involving any one handle (the ``active handle'') is defined elsewhere in this volume ofIEEE Std 1003.1-2001, but if two or more handles are used, and any one of them is a stream, the application shall ensurethat their actions are coordinated as described below. If this is not done, the result is undefined.</p><p>A handle which is a stream is considered to be closed when either an <a href="../functions/fclose.html"><i>fclose</i>()</a> or<a href="../functions/freopen.html"><i>freopen</i>()</a> is executed on it (the result of <a href="../functions/freopen.html"><i>freopen</i>()</a> is a new stream, which cannot be a handle on the same open file description as itsprevious value), or when the process owning that stream terminates with <a href="../functions/exit.html"><i>exit</i>()</a>, <ahref="../functions/abort.html"><i>abort</i>()</a>, or due to a signal. A file descriptor is closed by <a href="../functions/close.html"><i>close</i>()</a>, <a href="../functions/_exit.html"><i>_exit</i>()</a>, or the <i><a href="../functions/exec.html">exec</a></i> functions when FD_CLOEXEC is set on that file descriptor.</p><p>For a handle to become the active handle, the application shall ensure that the actions below are performed between the last useof the handle (the current active handle) and the first use of the second handle (the future active handle). The second handle thenbecomes the active handle. All activity by the application affecting the file offset on the first handle shall be suspended untilit again becomes the active file handle. (If a stream function has as an underlying function one that affects the file offset, thestream function shall be considered to affect the file offset.)</p><p>The handles need not be in the same process for these rules to apply.</p><p>Note that after a <a href="../functions/fork.html"><i>fork</i>()</a>, two handles exist where one existed before. Theapplication shall ensure that, if both handles can ever be accessed, they are both in a state where the other could become theactive handle first. The application shall prepare for a <a href="../functions/fork.html"><i>fork</i>()</a> exactly as if it were achange of active handle. (If the only action performed by one of the processes is one of the <i><a href="../functions/exec.html">exec</a></i> functions or <a href="../functions/_exit.html"><i>_exit</i>()</a> (not <a href="../functions/exit.html"><i>exit</i>()</a>), the handle is never accessed in that process.)</p><p>For the first handle, the first applicable condition below applies. After the actions required below are taken, if the handle isstill open, the application can close it.</p><ul><li><p>If it is a file descriptor, no action is required.</p></li><li><p>If the only further action to be performed on any handle to this open file descriptor is to close it, no action need betaken.</p></li><li><p>If it is a stream which is unbuffered, no action need be taken.</p></li><li><p>If it is a stream which is line buffered, and the last byte written to the stream was a <newline> (that is, as if a:</p><blockquote><pre><tt>putc('\n')</tt></pre></blockquote>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -