[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?


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