|
Home > Archive > Unix Programming > December 2007 > read() and EOF
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| David Mathog 2007-12-13, 1:24 pm |
| The linux man pages say that read() returns a 0 at end of file. Is
there a guarantee that it will continue to do that on subsequent read()
from the same fd, or is it conformant to return a 0 once, and then an
error after that? (I vaguely recall seeing that there are situations
where EOF is only returned once, but I could be mistaken.)
Thanks,
David Mathog
| |
| Rainer Weikusat 2007-12-13, 1:24 pm |
| David Mathog <mathog@caltech.edu> writes:
> The linux man pages say that read() returns a 0 at end of file. Is
> there a guarantee that it will continue to do that on subsequent
> read() from the same fd, or is it conformant to return a 0 once, and
> then an error after that? (I vaguely recall seeing that there are
> situations where EOF is only returned once, but I could be mistaken.)
One such situation would IIRC be a TCP socket which has been closed by
remote. The read will return an EOF indicator once and an error if
another read is attempted after this.
| |
| Kenny McCormack 2007-12-13, 1:24 pm |
| In article <87tzmm8qp8.fsf@fever.mssgmbh.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>David Mathog <mathog@caltech.edu> writes:
>
>One such situation would IIRC be a TCP socket which has been closed by
>remote. The read will return an EOF indicator once and an error if
>another read is attempted after this.
It is my understanding that the idea that "read() returns 0 on EOF" is
actually technically not true. One should say that "if read() returns
0, it means that no data is available AT THE PRESENT MOMENT". Now, on a
disk file (which is the most common case, obviously), this usually means
EOF, since disk files are pretty simple. But in other contexts, such as
a terminal in a non-blocking I/O mode, it could just mean that nothing
is available to be read now; this does not preclude that data could
become available at a later time.
| |
| Måns Rullgård 2007-12-13, 1:24 pm |
| gazelle@xmission.xmission.com (Kenny McCormack) writes:
> In article <87tzmm8qp8.fsf@fever.mssgmbh.com>,
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> It is my understanding that the idea that "read() returns 0 on EOF" is
> actually technically not true. One should say that "if read() returns
> 0, it means that no data is available AT THE PRESENT MOMENT". Now, on a
> disk file (which is the most common case, obviously), this usually means
> EOF, since disk files are pretty simple.
If someone makes the file larger, a subsequent read will succeed.
> But in other contexts, such as a terminal in a non-blocking I/O
> mode, it could just mean that nothing is available to be read now;
> this does not preclude that data could become available at a later
> time.
A read() call on a non-blocking file descriptor with no data available
shall return -1 and set errno to EAGAIN or EWOULDBLOCK. There is no
error code for end of file on a blocking file descriptor; a return
value of zero is used for that condition.
--
Måns Rullgård
mans@mansr.com
| |
| David Mathog 2007-12-13, 1:24 pm |
| Kenny McCormack wrote:
> But in other contexts, such as
> a terminal in a non-blocking I/O mode, it could just mean that nothing
> is available to be read now; this does not preclude that data could
> become available at a later time.
Shouldn't it return a -1, with errno set to EAGAIN for any device in a
nonblocking mode which does not have data ready?
Regards,
David Mathog
| |
| Casper H.S. Dik 2007-12-13, 1:24 pm |
| David Mathog <mathog@caltech.edu> writes:
>The linux man pages say that read() returns a 0 at end of file. Is
>there a guarantee that it will continue to do that on subsequent read()
>from the same fd, or is it conformant to return a 0 once, and then an
>error after that? (I vaguely recall seeing that there are situations
>where EOF is only returned once, but I could be mistaken.)
It will continue to return 0 until more data is written at the end of
the file.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
|
|
|
|
|