[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
read() and POSIX compliance
I've been putting some thought into making the MiNT library's read()
function POSIX compliant.
As it currently stands, the call will return 0 for a read on a device
if the device is positioned at end-of-file, or if the file handle is
marked O_NDELAY and no data is ready.
POSIX introduces the O_NONBLOCK flag which causes the read() to return
-1 with errno set to EAGAIN, when the file has no data available but
is not an end-of-file condition.
I'm thinking along these lines:
-call Fcntl(fd, &nbytes, FIONREAD)
-call Fread(...)
-if Fread() returns 0: then if nbytes is 0 return -1 with errno =
EAGAIN, otherwise return 0 signifying end-of file.
This seems valid for the TOS filesystem (since it always gives 1 for
FIONREAD it will never give EAGAIN) and for the pipefs (which will
give -1 for FIONREAD at end-of-file [that is, when the other side of
the pipe is closed] and 0 if there is just no data ready).
This reasoning breaks down, however, in the case of a device such as
the shmfs. This device will give 0 bytes for an FIONREAD when at
end-of-file, so using the above scheme would mean a non-blocking
read() on shmfs would never return 0.
I'm a bit stumped. I think it will be necessary to define the exact
action of FIONREAD at end-of-file for device drivers in some
consistent manner in order to make it possible to distinguish EOF from
a lack of available data.
Or am I just overlooking something?
Cheers,
entropy
--
entropy -- it's not just a good idea, it's the second law.
Personal mail: entropy@gnu.ai.mit.edu
MiNT library mail: entropy@terminator.rs.itd.umich.edu