1READ(3P) POSIX Programmer's Manual READ(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 pread, read - read from a file
13
15 #include <unistd.h>
16 ssize_t pread(int fildes, void *buf, size_t nbyte, off_t offset);
20 ssize_t read(int fildes, void *buf, size_t nbyte);
21
24 The read() function shall attempt to read nbyte bytes from the file
25 associated with the open file descriptor, fildes, into the buffer
26 pointed to by buf. The behavior of multiple concurrent reads on the
27 same pipe, FIFO, or terminal device is unspecified.
28 Before any action described below is taken, and if nbyte is zero, the
30 read() function may detect and return errors as described below. In the
31 absence of errors, or if error detection is not performed, the read()
32 function shall return zero and have no other results.
33 On files that support seeking (for example, a regular file), the read()
35 shall start at a position in the file given by the file offset associ‐
36 ated with fildes. The file offset shall be incremented by the number of
37 bytes actually read.
38 Files that do not support seeking-for example, terminals-always read
40 from the current position. The value of a file offset associated with
41 such a file is undefined.
42 No data transfer shall occur past the current end-of-file. If the
44 starting position is at or after the end-of-file, 0 shall be returned.
45 If the file refers to a device special file, the result of subsequent
46 read() requests is implementation-defined.
47 If the value of nbyte is greater than {SSIZE_MAX}, the result is imple‐
49 mentation-defined.
50 When attempting to read from an empty pipe or FIFO:
52 * If no process has the pipe open for writing, read() shall return 0
54 to indicate end-of-file.
55 * If some process has the pipe open for writing and O_NONBLOCK is set,
57 read() shall return -1 and set errno to [EAGAIN].
58 * If some process has the pipe open for writing and O_NONBLOCK is
60 clear, read() shall block the calling thread until some data is
61 written or the pipe is closed by all processes that had the pipe
62 open for writing.
63 When attempting to read a file (other than a pipe or FIFO) that sup‐
65 ports non-blocking reads and has no data currently available:
66 * If O_NONBLOCK is set, read() shall return -1 and set errno to
68 [EAGAIN].
69 * If O_NONBLOCK is clear, read() shall block the calling thread until
71 some data becomes available.
72 * The use of the O_NONBLOCK flag has no effect if there is some data
74 available.
75 The read() function reads data previously written to a file. If any
77 portion of a regular file prior to the end-of-file has not been writ‐
78 ten, read() shall return bytes with value 0. For example, lseek()
79 allows the file offset to be set beyond the end of existing data in the
80 file. If data is later written at this point, subsequent reads in the
81 gap between the previous end of data and the newly written data shall
82 return bytes with value 0 until data is written into the gap.
83 Upon successful completion, where nbyte is greater than 0, read() shall
85 mark for update the st_atime field of the file, and shall return the
86 number of bytes read. This number shall never be greater than nbyte.
87 The value returned may be less than nbyte if the number of bytes left
88 in the file is less than nbyte, if the read() request was interrupted
89 by a signal, or if the file is a pipe or FIFO or special file and has
90 fewer than nbyte bytes immediately available for reading. For example,
91 a read() from a file associated with a terminal may return one typed
92 line of data.
93 If a read() is interrupted by a signal before it reads any data, it
95 shall return -1 with errno set to [EINTR].
96 If a read() is interrupted by a signal after it has successfully read
98 some data, it shall return the number of bytes read.
99 For regular files, no data transfer shall occur past the offset maximum
101 established in the open file description associated with fildes.
102 If fildes refers to a socket, read() shall be equivalent to recv() with
104 no flags set.
105 If the O_DSYNC and O_RSYNC bits have been set, read I/O operations on
107 the file descriptor shall complete as defined by synchronized I/O data
108 integrity completion. If the O_SYNC and O_RSYNC bits have been set,
109 read I/O operations on the file descriptor shall complete as defined by
110 synchronized I/O file integrity completion.
111 If fildes refers to a shared memory object, the result of the read()
113 function is unspecified.
114 If fildes refers to a typed memory object, the result of the read()
116 function is unspecified.
117 A read() from a STREAMS file can read data in three different modes:
119 byte-stream mode, message-nondiscard mode, and message-discard mode.
120 The default shall be byte-stream mode. This can be changed using the
121 I_SRDOPT ioctl() request, and can be tested with I_GRDOPT ioctl(). In
122 byte-stream mode, read() shall retrieve data from the STREAM until as
123 many bytes as were requested are transferred, or until there is no more
124 data to be retrieved. Byte-stream mode ignores message boundaries.
125 In STREAMS message-nondiscard mode, read() shall retrieve data until as
127 many bytes as were requested are transferred, or until a message bound‐
128 ary is reached. If read() does not retrieve all the data in a message,
129 the remaining data shall be left on the STREAM, and can be retrieved by
130 the next read() call. Message-discard mode also retrieves data until
131 as many bytes as were requested are transferred, or a message boundary
132 is reached. However, unread data remaining in a message after the
133 read() returns shall be discarded, and shall not be available for a
134 subsequent read(), getmsg(), or getpmsg() call.
135 How read() handles zero-byte STREAMS messages is determined by the cur‐
137 rent read mode setting. In byte-stream mode, read() shall accept data
138 until it has read nbyte bytes, or until there is no more data to read,
139 or until a zero-byte message block is encountered. The read() function
140 shall then return the number of bytes read, and place the zero-byte
141 message back on the STREAM to be retrieved by the next read(),
142 getmsg(), or getpmsg(). In message-nondiscard mode or message-discard
143 mode, a zero-byte message shall return 0 and the message shall be
144 removed from the STREAM. When a zero-byte message is read as the first
145 message on a STREAM, the message shall be removed from the STREAM and 0
146 shall be returned, regardless of the read mode.
147 A read() from a STREAMS file shall return the data in the message at
149 the front of the STREAM head read queue, regardless of the priority
150 band of the message.
151 By default, STREAMs are in control-normal mode, in which a read() from
153 a STREAMS file can only process messages that contain a data part but
154 do not contain a control part. The read() shall fail if a message con‐
155 taining a control part is encountered at the STREAM head. This default
156 action can be changed by placing the STREAM in either control-data mode
157 or control-discard mode with the I_SRDOPT ioctl() command. In control-
158 data mode, read() shall convert any control part to data and pass it to
159 the application before passing any data part originally present in the
160 same message. In control-discard mode, read() shall discard message
161 control parts but return to the process any data part in the message.
162 In addition, read() shall fail if the STREAM head had processed an
164 asynchronous error before the call. In this case, the value of errno
165 shall not reflect the result of read(), but reflect the prior error. If
166 a hangup occurs on the STREAM being read, read() shall continue to
167 operate normally until the STREAM head read queue is empty. Thereafter,
168 it shall return 0.
169 The pread() function shall be equivalent to read(), except that it
171 shall read from a given position in the file without changing the file
172 pointer. The first three arguments to pread() are the same as read()
173 with the addition of a fourth argument offset for the desired position
174 inside the file. An attempt to perform a pread() on a file that is
175 incapable of seeking shall result in an error.
176
178 Upon successful completion, read() and pread() shall return a non-
179 negative integer indicating the number of bytes actually read. Other‐
180 wise, the functions shall return -1 and set errno to indicate the
181 error.
182
184 The read() and pread() functions shall fail if:
185 EAGAIN The O_NONBLOCK flag is set for the file descriptor and the
187 process would be delayed.
188 EBADF The fildes argument is not a valid file descriptor open for
190 reading.
191 EBADMSG
193 The file is a STREAM file that is set to control-normal mode and
194 the message waiting to be read includes a control part.
195 EINTR The read operation was terminated due to the receipt of a sig‐
197 nal, and no data was transferred.
198 EINVAL The STREAM or multiplexer referenced by fildes is linked
200 (directly or indirectly) downstream from a multiplexer.
201 EIO The process is a member of a background process attempting to
203 read from its controlling terminal, the process is ignoring or
204 blocking the SIGTTIN signal, or the process group is orphaned.
205 This error may also be generated for implementation-defined rea‐
206 sons.
207 EISDIR The fildes argument refers to a directory and the implementation
209 does not allow the directory to be read using read() or pread().
210 The readdir() function should be used instead.
211 EOVERFLOW
213 The file is a regular file, nbyte is greater than 0, the start‐
214 ing position is before the end-of-file, and the starting posi‐
215 tion is greater than or equal to the offset maximum established
216 in the open file description associated with fildes.
217 The read() function shall fail if:
220 EAGAIN or EWOULDBLOCK
222 The file descriptor is for a socket, is marked O_NONBLOCK, and
224 no data is waiting to be received.
225 ECONNRESET
227 A read was attempted on a socket and the connection was forcibly
228 closed by its peer.
229 ENOTCONN
231 A read was attempted on a socket that is not connected.
232 ETIMEDOUT
234 A read was attempted on a socket and a transmission timeout
235 occurred.
236 The read() and pread() functions may fail if:
239 EIO A physical I/O error has occurred.
241 ENOBUFS
243 Insufficient resources were available in the system to perform
244 the operation.
245 ENOMEM Insufficient memory was available to fulfill the request.
247 ENXIO A request was made of a nonexistent device, or the request was
249 outside the capabilities of the device.
250 The pread() function shall fail, and the file pointer shall remain
253 unchanged, if:
254 EINVAL The offset argument is invalid. The value is negative.
256 EOVERFLOW
258 The file is a regular file and an attempt was made to read at or
259 beyond the offset maximum associated with the file.
260 ENXIO A request was outside the capabilities of the device.
262 ESPIPE fildes is associated with a pipe or FIFO.
264 The following sections are informative.
267
269 Reading Data into a Buffer
270 The following example reads data from the file associated with the file
271 descriptor fd into the buffer pointed to by buf.
272 #include <sys/types.h>
275 #include <unistd.h>
276 ...
277 char buf[20];
278 size_t nbytes;
279 ssize_t bytes_read;
280 int fd;
281 ...
282 nbytes = sizeof(buf);
283 bytes_read = read(fd, buf, nbytes);
284 ...
285
287 None.
288
290 This volume of IEEE Std 1003.1-2001 does not specify the value of the
291 file offset after an error is returned; there are too many cases. For
292 programming errors, such as [EBADF], the concept is meaningless since
293 no file is involved. For errors that are detected immediately, such as
294 [EAGAIN], clearly the pointer should not change. After an interrupt or
295 hardware error, however, an updated value would be very useful and is
296 the behavior of many implementations.
297 Note that a read() of zero bytes does not modify st_atime. A read()
299 that requests more than zero bytes, but returns zero, shall modify
300 st_atime.
301 Implementations are allowed, but not required, to perform error check‐
303 ing for read() requests of zero bytes.
304 Input and Output
306 The use of I/O with large byte counts has always presented problems.
307 Ideas such as lread() and lwrite() (using and returning longs) were
308 considered at one time. The current solution is to use abstract types
309 on the ISO C standard function to read() and write(). The abstract
310 types can be declared so that existing functions work, but can also be
311 declared so that larger types can be represented in future implementa‐
312 tions. It is presumed that whatever constraints limit the maximum range
313 of size_t also limit portable I/O requests to the same range. This vol‐
314 ume of IEEE Std 1003.1-2001 also limits the range further by requiring
315 that the byte count be limited so that a signed return value remains
316 meaningful. Since the return type is also a (signed) abstract type, the
317 byte count can be defined by the implementation to be larger than an
318 int can hold.
319 The standard developers considered adding atomicity requirements to a
321 pipe or FIFO, but recognized that due to the nature of pipes and FIFOs
322 there could be no guarantee of atomicity of reads of {PIPE_BUF} or any
323 other size that would be an aid to applications portability.
324 This volume of IEEE Std 1003.1-2001 requires that no action be taken
326 for read() or write() when nbyte is zero. This is not intended to take
327 precedence over detection of errors (such as invalid buffer pointers or
328 file descriptors). This is consistent with the rest of this volume of
329 IEEE Std 1003.1-2001, but the phrasing here could be misread to require
330 detection of the zero case before any other errors. A value of zero is
331 to be considered a correct value, for which the semantics are a no-op.
332 I/O is intended to be atomic to ordinary files and pipes and FIFOs.
334 Atomic means that all the bytes from a single operation that started
335 out together end up together, without interleaving from other I/O oper‐
336 ations. It is a known attribute of terminals that this is not honored,
337 and terminals are explicitly (and implicitly permanently) excepted,
338 making the behavior unspecified. The behavior for other device types is
339 also left unspecified, but the wording is intended to imply that future
340 standards might choose to specify atomicity (or not).
341 There were recommendations to add format parameters to read() and
343 write() in order to handle networked transfers among heterogeneous file
344 system and base hardware types. Such a facility may be required for
345 support by the OSI presentation of layer services. However, it was
346 determined that this should correspond with similar C-language facili‐
347 ties, and that is beyond the scope of this volume of
348 IEEE Std 1003.1-2001. The concept was suggested to the developers of
349 the ISO C standard for their consideration as a possible area for
350 future work.
351 In 4.3 BSD, a read() or write() that is interrupted by a signal before
353 transferring any data does not by default return an [EINTR] error, but
354 is restarted. In 4.2 BSD, 4.3 BSD, and the Eighth Edition, there is an
355 additional function, select(), whose purpose is to pause until speci‐
356 fied activity (data to read, space to write, and so on) is detected on
357 specified file descriptors. It is common in applications written for
358 those systems for select() to be used before read() in situations (such
359 as keyboard input) where interruption of I/O due to a signal is
360 desired.
361 The issue of which files or file types are interruptible is considered
363 an implementation design issue. This is often affected primarily by
364 hardware and reliability issues.
365 There are no references to actions taken following an "unrecoverable
367 error". It is considered beyond the scope of this volume of
368 IEEE Std 1003.1-2001 to describe what happens in the case of hardware
369 errors.
370 Previous versions of IEEE Std 1003.1-2001 allowed two very different
372 behaviors with regard to the handling of interrupts. In order to mini‐
373 mize the resulting confusion, it was decided that IEEE Std 1003.1-2001
374 should support only one of these behaviors. Historical practice on
375 AT&T-derived systems was to have read() and write() return -1 and set
376 errno to [EINTR] when interrupted after some, but not all, of the data
377 requested had been transferred. However, the U.S. Department of Com‐
378 merce FIPS 151-1 and FIPS 151-2 require the historical BSD behavior, in
379 which read() and write() return the number of bytes actually trans‐
380 ferred before the interrupt. If -1 is returned when any data is trans‐
381 ferred, it is difficult to recover from the error on a seekable device
382 and impossible on a non-seekable device. Most new implementations sup‐
383 port this behavior. The behavior required by IEEE Std 1003.1-2001 is to
384 return the number of bytes transferred.
385 IEEE Std 1003.1-2001 does not specify when an implementation that buf‐
387 fers read()ss actually moves the data into the user-supplied buffer, so
388 an implementation may chose to do this at the latest possible moment.
389 Therefore, an interrupt arriving earlier may not cause read() to return
390 a partial byte count, but rather to return -1 and set errno to [EINTR].
391 Consideration was also given to combining the two previous options, and
393 setting errno to [EINTR] while returning a short count. However, not
394 only is there no existing practice that implements this, it is also
395 contradictory to the idea that when errno is set, the function respon‐
396 sible shall return -1.
397
399 None.
400
402 fcntl(), ioctl(), lseek(), open(), pipe(), readv(), the Base Defini‐
403 tions volume of IEEE Std 1003.1-2001, Chapter 11, General Terminal
404 Interface, <stropts.h>, <sys/uio.h>, <unistd.h>
405
407 Portions of this text are reprinted and reproduced in electronic form
408 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
409 -- Portable Operating System Interface (POSIX), The Open Group Base
410 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
411 Electrical and Electronics Engineers, Inc and The Open Group. In the
412 event of any discrepancy between this version and the original IEEE and
413 The Open Group Standard, the original IEEE and The Open Group Standard
414 is the referee document. The original Standard can be obtained online
415 at http://www.opengroup.org/unix/online.html .
416IEEE/The Open Group 2003 READ(3P)