Originální popis anglicky:
pread, read - read from a file
Návod, kniha: POSIX Programmer's Manual
#include <unistd.h>
ssize_t pread(int fildes, void *buf, size_t
nbyte, off_t offset);
ssize_t read(int
fildes, void
*buf , size_t
nbyte );
The
read() function shall attempt to read
nbyte bytes from the
file associated with the open file descriptor,
fildes, into the buffer
pointed to by
buf. The behavior of multiple concurrent reads on the
same pipe, FIFO, or terminal device is unspecified.
Before any action described below is taken, and if
nbyte is zero, the
read() function may detect and return errors as described below. In the
absence of errors, or if error detection is not performed, the
read()
function shall return zero and have no other results.
On files that support seeking (for example, a regular file), the
read()
shall start at a position in the file given by the file offset associated with
fildes. The file offset shall be incremented by the number of bytes
actually read.
Files that do not support seeking-for example, terminals-always read from the
current position. The value of a file offset associated with such a file is
undefined.
No data transfer shall occur past the current end-of-file. If the starting
position is at or after the end-of-file, 0 shall be returned. If the file
refers to a device special file, the result of subsequent
read()
requests is implementation-defined.
If the value of
nbyte is greater than {SSIZE_MAX}, the result is
implementation-defined.
When attempting to read from an empty pipe or FIFO:
- *
- If no process has the pipe open for writing, read()
shall return 0 to indicate end-of-file.
- *
- If some process has the pipe open for writing and
O_NONBLOCK is set, read() shall return -1 and set errno to
[EAGAIN].
- *
- If some process has the pipe open for writing and
O_NONBLOCK is clear, read() shall block the calling thread until
some data is written or the pipe is closed by all processes that had the
pipe open for writing.
When attempting to read a file (other than a pipe or FIFO) that supports
non-blocking reads and has no data currently available:
- *
- If O_NONBLOCK is set, read() shall return -1 and set
errno to [EAGAIN].
- *
- If O_NONBLOCK is clear, read() shall block the
calling thread until some data becomes available.
- *
- The use of the O_NONBLOCK flag has no effect if there is
some data available.
The
read() function reads data previously written to a file. If any
portion of a regular file prior to the end-of-file has not been written,
read() shall return bytes with value 0. For example,
lseek()
allows the file offset to be set beyond the end of existing data in the file.
If data is later written at this point, subsequent reads in the gap between
the previous end of data and the newly written data shall return bytes with
value 0 until data is written into the gap.
Upon successful completion, where
nbyte is greater than 0,
read()
shall mark for update the
st_atime field of the file, and shall return
the number of bytes read. This number shall never be greater than
nbyte. The value returned may be less than
nbyte if the number
of bytes left in the file is less than
nbyte, if the
read()
request was interrupted by a signal, or if the file is a pipe or FIFO or
special file and has fewer than
nbyte bytes immediately available for
reading. For example, a
read() from a file associated with a terminal
may return one typed line of data.
If a
read() is interrupted by a signal before it reads any data, it shall
return -1 with
errno set to [EINTR].
If a
read() is interrupted by a signal after it has successfully read
some data, it shall return the number of bytes read.
For regular files, no data transfer shall occur past the offset maximum
established in the open file description associated with
fildes.
If
fildes refers to a socket,
read() shall be equivalent to
recv() with no flags set.
If the O_DSYNC and O_RSYNC bits have been set, read I/O operations on the file
descriptor shall complete as defined by synchronized I/O data integrity
completion. If the O_SYNC and O_RSYNC bits have been set, read I/O operations
on the file descriptor shall complete as defined by synchronized I/O file
integrity completion.
If
fildes refers to a shared memory object, the result of the
read() function is unspecified.
If
fildes refers to a typed memory object, the result of the
read() function is unspecified.
A
read() from a STREAMS file can read data in three different modes:
byte-stream mode,
message-nondiscard mode, and
message-discard mode. The default shall be byte-stream mode. This can
be changed using the I_SRDOPT
ioctl() request, and can be tested with
I_GRDOPT
ioctl(). In byte-stream mode,
read() shall retrieve
data from the STREAM until as many bytes as were requested are transferred, or
until there is no more data to be retrieved. Byte-stream mode ignores message
boundaries.
In STREAMS message-nondiscard mode,
read() shall retrieve data until as
many bytes as were requested are transferred, or until a message boundary is
reached. If
read() does not retrieve all the data in a message, the
remaining data shall be left on the STREAM, and can be retrieved by the next
read() call. Message-discard mode also retrieves data until as many
bytes as were requested are transferred, or a message boundary is reached.
However, unread data remaining in a message after the
read() returns
shall be discarded, and shall not be available for a subsequent
read(),
getmsg(), or
getpmsg() call.
How
read() handles zero-byte STREAMS messages is determined by the
current read mode setting. In byte-stream mode,
read() shall accept
data until it has read
nbyte bytes, or until there is no more data to
read, or until a zero-byte message block is encountered. The
read()
function shall then return the number of bytes read, and place the zero-byte
message back on the STREAM to be retrieved by the next
read(),
getmsg(), or
getpmsg(). In message-nondiscard mode or
message-discard mode, a zero-byte message shall return 0 and the message shall
be removed from the STREAM. When a zero-byte message is read as the first
message on a STREAM, the message shall be removed from the STREAM and 0 shall
be returned, regardless of the read mode.
A
read() from a STREAMS file shall return the data in the message at the
front of the STREAM head read queue, regardless of the priority band of the
message.
By default, STREAMs are in control-normal mode, in which a
read() from a
STREAMS file can only process messages that contain a data part but do not
contain a control part. The
read() shall fail if a message containing a
control part is encountered at the STREAM head. This default action can be
changed by placing the STREAM in either control-data mode or control-discard
mode with the I_SRDOPT
ioctl() command. In control-data mode,
read() shall convert any control part to data and pass it to the
application before passing any data part originally present in the same
message. In control-discard mode,
read() shall discard message control
parts but return to the process any data part in the message.
In addition,
read() shall fail if the STREAM head had processed an
asynchronous error before the call. In this case, the value of
errno
shall not reflect the result of
read(), but reflect the prior error. If
a hangup occurs on the STREAM being read,
read() shall continue to
operate normally until the STREAM head read queue is empty. Thereafter, it
shall return 0.
The
pread() function shall be equivalent to
read(), except that it
shall read from a given position in the file without changing the file
pointer. The first three arguments to
pread() are the same as
read() with the addition of a fourth argument
offset for the
desired position inside the file. An attempt to perform a
pread() on a
file that is incapable of seeking shall result in an error.
Upon successful completion,
read() and
pread() shall
return a non-negative integer indicating the number of bytes actually read.
Otherwise, the functions shall return -1 and set
errno to indicate the
error.
The
read() and
pread() functions shall fail if:
- EAGAIN
- The O_NONBLOCK flag is set for the file descriptor and the
process would be delayed.
- EBADF
- The fildes argument is not a valid file descriptor
open for reading.
- EBADMSG
- The file is a STREAM file that is set to control-normal
mode and the message waiting to be read includes a control part.
- EINTR
- The read operation was terminated due to the receipt of a
signal, and no data was transferred.
- EINVAL
- The STREAM or multiplexer referenced by fildes is
linked (directly or indirectly) downstream from a multiplexer.
- EIO
- The process is a member of a background process attempting
to read from its controlling terminal, the process is ignoring or blocking
the SIGTTIN signal, or the process group is orphaned. This error may also
be generated for implementation-defined reasons.
- EISDIR
- The fildes argument refers to a directory and the
implementation does not allow the directory to be read using read()
or pread(). The readdir() function should be used
instead.
- EOVERFLOW
- The file is a regular file, nbyte is greater than 0,
the starting position is before the end-of-file, and the starting position
is greater than or equal to the offset maximum established in the open
file description associated with fildes.
The
read() function shall fail if:
- EAGAIN or EWOULDBLOCK
-
The file descriptor is for a socket, is marked O_NONBLOCK, and no data is
waiting to be received.
- ECONNRESET
- A read was attempted on a socket and the connection was
forcibly closed by its peer.
- ENOTCONN
- A read was attempted on a socket that is not
connected.
- ETIMEDOUT
- A read was attempted on a socket and a transmission timeout
occurred.
The
read() and
pread() functions may fail if:
- EIO
- A physical I/O error has occurred.
- ENOBUFS
- Insufficient resources were available in the system to
perform the operation.
- ENOMEM
- Insufficient memory was available to fulfill the
request.
- ENXIO
- A request was made of a nonexistent device, or the request
was outside the capabilities of the device.
The
pread() function shall fail, and the file pointer shall remain
unchanged, if:
- EINVAL
- The offset argument is invalid. The value is
negative.
- EOVERFLOW
- The file is a regular file and an attempt was made to read
at or beyond the offset maximum associated with the file.
- ENXIO
- A request was outside the capabilities of the device.
- ESPIPE
- fildes is associated with a pipe or FIFO.
The following sections are informative.
The following example reads data from the file associated with the file
descriptor
fd into the buffer pointed to by
buf.
#include <sys/types.h>
#include <unistd.h>
...
char buf[20];
size_t nbytes;
ssize_t bytes_read;
int fd;
...
nbytes = sizeof(buf);
bytes_read = read(fd, buf, nbytes);
...
None.
This volume of IEEE Std 1003.1-2001 does not specify the value of
the file offset after an error is returned; there are too many cases. For
programming errors, such as [EBADF], the concept is meaningless since no file
is involved. For errors that are detected immediately, such as [EAGAIN],
clearly the pointer should not change. After an interrupt or hardware error,
however, an updated value would be very useful and is the behavior of many
implementations.
Note that a
read() of zero bytes does not modify
st_atime. A
read() that requests more than zero bytes, but returns zero, shall
modify
st_atime.
Implementations are allowed, but not required, to perform error checking for
read() requests of zero bytes.
The use of I/O with large byte counts has always presented problems. Ideas such
as
lread() and
lwrite() (using and returning
longs) were
considered at one time. The current solution is to use abstract types on the
ISO C standard function to
read() and
write(). The
abstract types can be declared so that existing functions work, but can also
be declared so that larger types can be represented in future implementations.
It is presumed that whatever constraints limit the maximum range of
size_t also limit portable I/O requests to the same range. This volume
of IEEE Std 1003.1-2001 also limits the range further by
requiring that the byte count be limited so that a signed return value remains
meaningful. Since the return type is also a (signed) abstract type, the byte
count can be defined by the implementation to be larger than an
int can
hold.
The standard developers considered adding atomicity requirements to a pipe or
FIFO, but recognized that due to the nature of pipes and FIFOs there could be
no guarantee of atomicity of reads of {PIPE_BUF} or any other size that would
be an aid to applications portability.
This volume of IEEE Std 1003.1-2001 requires that no action be
taken for
read() or
write() when
nbyte is zero. This is
not intended to take precedence over detection of errors (such as invalid
buffer pointers or file descriptors). This is consistent with the rest of this
volume of IEEE Std 1003.1-2001, but the phrasing here could be
misread to require detection of the zero case before any other errors. A value
of zero is to be considered a correct value, for which the semantics are a
no-op.
I/O is intended to be atomic to ordinary files and pipes and FIFOs. Atomic means
that all the bytes from a single operation that started out together end up
together, without interleaving from other I/O operations. It is a known
attribute of terminals that this is not honored, and terminals are explicitly
(and implicitly permanently) excepted, making the behavior unspecified. The
behavior for other device types is also left unspecified, but the wording is
intended to imply that future standards might choose to specify atomicity (or
not).
There were recommendations to add format parameters to
read() and
write() in order to handle networked transfers among heterogeneous file
system and base hardware types. Such a facility may be required for support by
the OSI presentation of layer services. However, it was determined that this
should correspond with similar C-language facilities, and that is beyond the
scope of this volume of IEEE Std 1003.1-2001. The concept was
suggested to the developers of the ISO C standard for their
consideration as a possible area for future work.
In 4.3 BSD, a
read() or
write() that is interrupted by a signal
before transferring any data does not by default return an [EINTR] error, but
is restarted. In 4.2 BSD, 4.3 BSD, and the Eighth Edition, there is an
additional function,
select(), whose purpose is to pause until
specified activity (data to read, space to write, and so on) is detected on
specified file descriptors. It is common in applications written for those
systems for
select() to be used before
read() in situations
(such as keyboard input) where interruption of I/O due to a signal is desired.
The issue of which files or file types are interruptible is considered an
implementation design issue. This is often affected primarily by hardware and
reliability issues.
There are no references to actions taken following an "unrecoverable
error". It is considered beyond the scope of this volume of
IEEE Std 1003.1-2001 to describe what happens in the case of
hardware errors.
Previous versions of IEEE Std 1003.1-2001 allowed two very
different behaviors with regard to the handling of interrupts. In order to
minimize the resulting confusion, it was decided that
IEEE Std 1003.1-2001 should support only one of these behaviors.
Historical practice on AT&T-derived systems was to have
read() and
write() return -1 and set
errno to [EINTR] when interrupted
after some, but not all, of the data requested had been transferred. However,
the U.S. Department of Commerce FIPS 151-1 and FIPS 151-2 require the
historical BSD behavior, in which
read() and
write() return the
number of bytes actually transferred before the interrupt. If -1 is returned
when any data is transferred, it is difficult to recover from the error on a
seekable device and impossible on a non-seekable device. Most new
implementations support this behavior. The behavior required by
IEEE Std 1003.1-2001 is to return the number of bytes
transferred.
IEEE Std 1003.1-2001 does not specify when an implementation that
buffers
read()ss actually moves the data into the user-supplied buffer,
so an implementation may chose to do this at the latest possible moment.
Therefore, an interrupt arriving earlier may not cause
read() to return
a partial byte count, but rather to return -1 and set
errno to [EINTR].
Consideration was also given to combining the two previous options, and setting
errno to [EINTR] while returning a short count. However, not only is
there no existing practice that implements this, it is also contradictory to
the idea that when
errno is set, the function responsible shall return
-1.
None.
fcntl() ,
ioctl() ,
lseek() ,
open() ,
pipe()
,
readv() , the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 11, General Terminal Interface,
<stropts.h>,
<sys/uio.h>,
<unistd.h>
Portions of this text are reprinted and reproduced in electronic form from IEEE
Std 1003.1, 2003 Edition, Standard for Information Technology -- Portable
Operating System Interface (POSIX), The Open Group Base Specifications Issue
6, Copyright (C) 2001-2003 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. In the event of any discrepancy between
this version and the original IEEE and The Open Group Standard, the original
IEEE and The Open Group Standard is the referee document. The original
Standard can be obtained online at http://www.opengroup.org/unix/online.html
.
