1READ(3P)                   POSIX Programmer's Manual                  READ(3P)
2
3
4

PROLOG

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

NAME

12       pread, read - read from a file
13

SYNOPSIS

15       #include <unistd.h>
16
17
18
19       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
22

DESCRIPTION

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
29       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
34       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
39       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
43       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
48       If the value of nbyte is greater than {SSIZE_MAX}, the result is imple‐
49       mentation-defined.
50
51       When attempting to read from an empty pipe or FIFO:
52
53        * If  no  process has the pipe open for writing, read() shall return 0
54          to indicate end-of-file.
55
56        * 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
59        * 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
64       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
67        * If  O_NONBLOCK  is  set,  read()  shall  return  -1 and set errno to
68          [EAGAIN].
69
70        * If O_NONBLOCK is clear, read() shall block the calling thread  until
71          some data becomes available.
72
73        * The  use  of the O_NONBLOCK flag has no effect if there is some data
74          available.
75
76       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
84       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
94       If a read() is interrupted by a signal before it  reads  any  data,  it
95       shall return -1 with errno set to [EINTR].
96
97       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
100       For regular files, no data transfer shall occur past the offset maximum
101       established in the open file description associated with fildes.
102
103       If fildes refers to a socket, read() shall be equivalent to recv() with
104       no flags set.
105
106       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
112       If fildes refers to a shared memory object, the result  of  the  read()
113       function is unspecified.
114
115       If  fildes  refers  to  a typed memory object, the result of the read()
116       function is unspecified.
117
118       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
126       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
136       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
148       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
152       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
163       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
170       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

RETURN VALUE

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

ERRORS

184       The read() and   pread()  functions shall fail if:
185
186       EAGAIN The O_NONBLOCK flag is set  for  the  file  descriptor  and  the
187              process would be delayed.
188
189       EBADF  The  fildes  argument  is  not  a valid file descriptor open for
190              reading.
191
192       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
196       EINTR  The  read  operation was terminated due to the receipt of a sig‐
197              nal, and no data was transferred.
198
199       EINVAL The  STREAM  or  multiplexer  referenced  by  fildes  is  linked
200              (directly or indirectly) downstream from a multiplexer.
201
202       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
208       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
212       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
218
219       The read() function shall fail if:
220
221       EAGAIN or EWOULDBLOCK
222
223              The file descriptor is for a socket, is marked  O_NONBLOCK,  and
224              no data is waiting to be received.
225
226       ECONNRESET
227              A read was attempted on a socket and the connection was forcibly
228              closed by its peer.
229
230       ENOTCONN
231              A read was attempted on a socket that is not connected.
232
233       ETIMEDOUT
234              A read was attempted on a  socket  and  a  transmission  timeout
235              occurred.
236
237
238       The read() and   pread()  functions may fail if:
239
240       EIO    A physical I/O error has occurred.
241
242       ENOBUFS
243              Insufficient  resources  were available in the system to perform
244              the operation.
245
246       ENOMEM Insufficient memory was available to fulfill the request.
247
248       ENXIO  A request was made of a nonexistent device, or the  request  was
249              outside the capabilities of the device.
250
251
252       The  pread()  function  shall  fail,  and the file pointer shall remain
253       unchanged, if:
254
255       EINVAL The offset argument is invalid. The value is negative.
256
257       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
261       ENXIO  A request was outside the capabilities of the device.
262
263       ESPIPE fildes is associated with a pipe or FIFO.
264
265
266       The following sections are informative.
267

EXAMPLES

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
273
274              #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

APPLICATION USAGE

287       None.
288

RATIONALE

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
298       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
302       Implementations are allowed, but not required, to perform error  check‐
303       ing for read() requests of zero bytes.
304
305   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
320       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
325       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
333       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
342       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
352       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
362       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
366       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
371       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
386       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
392       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

FUTURE DIRECTIONS

399       None.
400

SEE ALSO

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 .
416
417
418
419IEEE/The Open Group                  2003                             READ(3P)
Impressum