From c80a5b628ca438e553b818c6d6a8764bd10d3f90 Mon Sep 17 00:00:00 2001 From: sperber Date: Thu, 28 Nov 2002 12:10:40 +0000 Subject: [PATCH] Consistently replace "i/o" -> "I/O". --- doc/scsh-manual/syscalls.tex | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/scsh-manual/syscalls.tex b/doc/scsh-manual/syscalls.tex index 688c22a..fdb0769 100644 --- a/doc/scsh-manual/syscalls.tex +++ b/doc/scsh-manual/syscalls.tex @@ -134,7 +134,7 @@ This can be overridden if the programmer wishes. \subsection{Standard {\RnRS} I/O procedures} In scsh, most standard {\RnRS} i/o operations (such as \ex{display} or \ex{read-char}) work on both integer file descriptors and {\Scheme} ports. -When doing i/o with a file descriptor, the i/o operation is done +When doing I/O with a file descriptor, the I/O operation is done directly on the file, bypassing any buffered data that may have accumulated in an associated port. Note that character-at-a-time operations such as \ex{read-char} @@ -297,10 +297,10 @@ You may safely skim or completely skip this section on a first reading. Dealing with {\Unix} file descriptors in a {\Scheme} environment is difficult. In {\Unix}, open files are part of the process environment, and are referenced by small integers called \emph{file descriptors}. Open file descriptors are -the fundamental way i/o redirections are passed to subprocesses, since +the fundamental way I/O redirections are passed to subprocesses, since file descriptors are preserved across fork's and exec's. -{\Scheme}, on the other hand, uses ports for specifying i/o sources. Ports are +{\Scheme}, on the other hand, uses ports for specifying I/O sources. Ports are garbage-collected {\Scheme} objects, not integers. Ports can be garbage collected; when a port is collected, it is also closed. Because file descriptors are just integers, it's impossible to garbage collect them---you @@ -593,7 +593,7 @@ this is dependent on the OS implementation. The returned port is an input port if the \var{flags} permit it, otherwise an output port. \RnRS/\scm/scsh do not have input/output ports, so it's one or the other. This should be fixed. (You can hack simultaneous - i/o on a file by opening it r/w, taking the result input port, + I/O on a file by opening it r/w, taking the result input port, and duping it to an output port with \ex{dup->outport}.) \end{defundesc} @@ -746,7 +746,7 @@ Returns two ports, the read and write end-points of a {\Unix} pipe. (barring eof). There is one case in which the forward-progress guarantee is cancelled: - when the programmer explicitly sets the port to non-blocking i/o. + when the programmer explicitly sets the port to non-blocking I/O. In this case, if no data is immediately available, the procedure will not block, but will immediately return a zero-byte read. @@ -764,7 +764,7 @@ Returns two ports, the read and write end-points of a {\Unix} pipe. A request to read zero bytes returns immediatedly, with no eof check. In sum, there are only three ways you can get a zero-byte read: - (1) you request one, (2) you turn on non-blocking i/o, or (3) you + (1) you request one, (2) you turn on non-blocking I/O, or (3) you try to read at eof. These are the routines to use for non-blocking input. @@ -868,7 +868,7 @@ Returns two ports, the read and write end-points of a {\Unix} pipe. (due to interrupts or partial writes), it will perform multiple write operations until all the data is written or an error has occurred. - A non-blocking i/o error is considered an error. + A non-blocking I/O error is considered an error. (Error exception packets for this syscall include the amount of data partially transferred before the error occurred.) @@ -893,9 +893,9 @@ Returns two ports, the read and write end-points of a {\Unix} pipe. asked for. Partial writes can occur when (1) we write off the physical end of the media, (2) the write is interrrupted, or (3) the file descriptor - is set for non-blocking i/o. + is set for non-blocking I/O. - If the file descriptor is not set up for non-blocking i/o, then + If the file descriptor is not set up for non-blocking I/O, then a successful return from these procedures makes a forward progress guarantee---that is, a partial write took place of at least one byte: \begin{itemize} @@ -908,14 +908,14 @@ Returns two ports, the read and write end-points of a {\Unix} pipe. \end{itemize} If we request a zero-byte write, then the call immediately returns 0. - If the file descriptor is set for non-blocking i/o, then the call + If the file descriptor is set for non-blocking I/O, then the call may return 0 if it was unable to immediately write anything (\eg, full pipe). Barring these two cases, a write either returns $\var{nwritten} > 0$, or raises an error exception. - Non-blocking i/o is only available on file descriptors and unbuffered - ports. Doing non-blocking i/o to a buffered port is not well-defined, + Non-blocking I/O is only available on file descriptors and unbuffered + ports. Doing non-blocking I/O to a buffered port is not well-defined, and is an error (the problem is the subsequent flush operation). \end{defundescx} @@ -1654,7 +1654,7 @@ delimiter. that collisions are less likely to occur. This speeds things up, but does not affect correctness. - Security note: doing i/o to files created this way in \ex{/var/tmp/} is + Security note: doing I/O to files created this way in \ex{/var/tmp/} is not necessarily secure. General users have write access to \ex{/var/tmp/}, so even if an attacker cannot access the new temp file, he can delete it and replace it with one of his own. A subsequent open of this filename @@ -1766,7 +1766,7 @@ delimiter. simply see and report an end of file. This is bad. In order to ensure that an end-of-file returned to the reader is - legitimate, the reader and writer must serialise their i/o. The + legitimate, the reader and writer must serialise their I/O. The simplest way to do this is for the reader to delay doing input until the writer has completely finished doing output, or exited. \end{itemize}