EOF or not EOF?

Hi,

Using only low-level POSIX I/O (i.e. no CRT FILE*-related functions), I've got this problem: I open a file in non-blocking mode:

Code:

---

int fd = ::open(filename, O_RDONLY | O_NONBLOCK);

---

Then I perform a read operation on it:

Code:

---

ssize_t count = ::read(fd, buffer, buffersize);

---

OK, now there might be various results. First, the function might return -1. Then I check errno. Most of the values aren't interesting: EBADF, EFAULT and some cases of EINVAL are programming errors, EISDIR and the remaining EINVAL errors user errors. EIO is the Murphy case. So far, so good.

EINTR is problematic because it's unpredictable, but on non-blocking I/O, it shouldn't be very common. If it is returned, the read position of the file isn't exactly defined, which is bad, but I can't do anything about it.

EAGAIN is returned if there is no data available for reading, but EOF hasn't been reached. (We're still in non-blocking mode.) That's the best error case, because I know exactly what happened, and it's good.


OR the function might return 0. That's good, too: EOF is reached, no data was available.

OR the function might return a value == buffersize. That's good too, because the operation completed.

OR the function might return a value between 0 and buffersize. And that's bad. It might be because EOF has been reached before buffersize bytes could be read. Or it might be because no more data was available, so it would have blocked, but a bit of data has been read. Or it might be because a signal interrupted the call after some data had been read. (The POSIX spec allows the function to succeed with a partial read in such cases.) But how do I tell which happened? I need to inform the caller whether he should expect more data in the future, or whether EOF has really been reached. I cannot issue another read: some data sources don't support seeking, and I don't want to implement buffering of a character just for this.

Basically, I'd like a low-level equivalent of feof(), but it seems there is none.

I'm currently inclined to just claim that there might be more data available - since you can't know, the program must be able to handle a total failure of the next read anyway. But I'd like to know if there's a better way.

Is it really a file that you're opening?
I always thought that a disk file was considered fast enough to not really benefit from non-blocking I/O.

Or is this a more abstract 'file' which could be any device.


> EINTR is problematic because it's unpredictable
What is your information source?
According to this, EINTR can only be returned BEFORE any data is read. My assumption was that it would return whatever it had received up until the interrupt.

> I need to inform the caller whether he should expect more data in the future,
> or whether EOF has really been reached.
Why?
I mean, you already have "OR the function might return 0" case handled anyway, so what's the problem calling the function one more time for it to immediately return 0 ?

> Basically, I'd like a low-level equivalent of feof(), but it seems there is none.
But feof() relies on one failed read in order to set the end of file status anyway.
You can seek to the end of the file, or read all 'n' bytes from an 'n' byte file, and neither in themselves cause EOF/feof() to become asserted.

Quote:

---

Originally Posted by Salem

Is it really a file that you're opening?
I always thought that a disk file was considered fast enough to not really benefit from non-blocking I/O.

Or is this a more abstract 'file' which could be any device.

---

It's a library, so I have no idea what will be opened.

Quote:

---

> EINTR is problematic because it's unpredictable
What is your information source?

---

My system's man pages. You're right, I overlooked where it said that EINTR is only set if no data was read. This is probably Linux-specific, though; the man page also says this:
"POSIX allows a read() that is interrupted after reading some data to return -1 (with errno set to EINTR) or to return the number of bytes already read."

Quote:

---

I mean, you already have "OR the function might return 0" case handled anyway, so what's the problem calling the function one more time for it to immediately return 0 ?

---

Good point. I'll go with my plan then.

Code:

---

        return is_blocking() || count == 0 || count == target.size() ?
                complete : wouldblock;

---

Thanks.